\documentclass[12pt]{report}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

\usepackage{amsmath,amssymb,amsfonts}
\usepackage{array}
\usepackage{color}
\usepackage{float}
\usepackage{geometry}
\usepackage{graphicx}
\usepackage{listings}
\usepackage{longtable}
\usepackage{rotating}
%\usepackage{txfonts} nie używać, psuje longtable
\usepackage{url}
\usepackage{fancyhdr}

\newcolumntype{M}{>{\centering\arraybackslash}m{6cm}}
\newcolumntype{L}{>{\centering\arraybackslash}m{5cm}}
\newcolumntype{C}{>{\centering\arraybackslash}m{3cm}}

\renewcommand{\chaptername}{Rozdział}
\renewcommand{\contentsname}{Spis treści}
\renewcommand{\figurename}{Rys.}
\renewcommand{\tablename}{Tab.}
\renewcommand{\listfigurename}{Spis rysunków}
\renewcommand{\listtablename}{Spis tabel}
\renewcommand{\bibname}{Bibliografia}

\pagestyle{headings}

\setlength{\textwidth}{14cm}
\setlength{\textheight}{20cm}

\setcounter{page}{2}

\newtheorem{definition}{Definicja} % przykład nowego środowiska 
\newtheorem{example}{Przykład}[chapter] % przykład nowego środowiska 
\newtheorem{corollary}{Wniosek}[chapter] % przykład nowego środowiska 

%Zarządzanie warstwą modelu za pomocą Business Components w technologii 
%Oracle Application Development Framework

%numeracja stron na dole strony, pośrodku
\pagestyle{fancy}\chead{}\rhead{}\lfoot{}\cfoot{\thepage}\rfoot{}

\begin{document}
\tableofcontents	% generuje spis treści ze stronami

\chapter{Wstęp} \label{rozdz.wstep} 
\indent  \\ \indent Niniejsza praca dotyczy możliwości stosowania komponentów biznesowych podczas zarządzania bazą danych. 
Głównym celem pracy jest poznanie sposo\-bów
zarządzania modelem w technologii ADF (ang. {\it{Application Development Framework }}), porównując je do podstawowych metod z poziomu 
SQL (ang. {\it{Structured Query Language }}). Autor chce również dokonać anali\-zy
użycia komponentów biznesowych podczas pracy z warstwą modelu. 
W pracy skoncentrowano się na zagadnieniach związanych ze strukturą oraz budową obiektów frameworka, służących do obsługi danych. 
Zamieszczone zostało również wyjaśnienie użycia poszczególnych elementów zarządzania modelem. Autor opisał temat zarówno pod względem teoretycznym 
jak i praktycznym. Poszczególne opisy biznesowych komponentów pozwalają poznać cel ich użycia oraz zastosowania w aplikacjach webowych. \\ 
Technologia ADF jest stosunkowo nową technologią, jak na standardy informatyczne, dlatego nie jest powszechnie używana. 
Niniejsza praca pozwala le\-piej poznać technologię, a tym samym zwiększyła grono użytkowników, którzy zaczną jej używać w swojej codziennej 
pracy z bazami danych oraz z warstwą modelu. \\
Wybierając temat pracy magisterskiej autor kierował się chęcią opracowania wnikliwej analizy komponentów biznesowych. Wymagało to
zatem zdobycia wiedzy zarówno technicznej, jak i praktycznej z dziedziny frameworka ADF. Efektem jest kompletne przedstawienie
struktury sposobu dostępu do modelu, zarówno pod kątem teoretycznym jak i praktycznym. Pozwoli to innym na dokładne poznanie zasad działa\-nia 
obiektów biznesowych.\\
Przeprowadzone testy oraz porównanie mniej popularnej technologii do ogólnie znanego sposobu, jakim jest
język SQL umożliwia czytelnikowi zdobycie wiedzy związanej z sposobami dostępu do danych. 

\section{Problematyka oraz cel pracy}
Podstawowym celem pracy jest poznanie sposobów zarządzania modelem na tle 
metod związanych z językiem SQL oraz analiza użycia komponentów biznesowych. Wymagało to od autora zdobycia wiedzy o strukturze i użyciu komponentów
biznesowych. Na tle operowania SQL-em, dostrzec można bardzo duże różnice w sposobie dostępu do danych, co autor opisuje w swojej pracy.
Weryfikacja wielu przykładowych aplikacji demonstrujących mapowanie stru\-ktury modelu pozwoliło dobrze poznać zaprojektowane wzorce. \\
Poznanie nowego sposobu zarządzania danymi wymusza wykonanie analizy oraz porównanie danej technologii z inną. Spodziewanym efektem 
jest wskaza\-nie zalet i wad poszczególnych rozwiązań oraz wybranie lepszego sposobu dostępu do danych. Autor podczas realizacji tematu
wybrał kilka kryteriów porównania:
\begin{itemize}
\item wydajność – została dokonana analiza wydajności podczas dostępu oraz modyfikacji danych,
\item wygoda użycia – subiektywne odczucia autora podczas używania obu technologii, określające której technologii używa się wygodniej,
\item trudność modelowania - należy ocenić, czy poznanie struktury BC (ang. {\it{Business Components }}) oraz ich implementacja wymusza 
znajomość
spec\-ja\-listycznej wiedzy, bez której korzystanie z BC może okazać się niemożli\-we,
\item zastosowanie - podczas porównywania okazało się, że obie technologie mają zastosowania, w których będą sprawować się lepiej, 
należy w takim wypadku sprawdzić oraz opisać w jakich zastosowaniach można stosować poszczególne rozwiązania.
\end{itemize}
Przedstawione powyżej kryteria w wystarczający sposób pozwoliły na wykonanie porównania oraz oceny technologii. Autor ma nadzieję, że 
umożliwi to innym osobom dokonanie wyboru, którego sposóbu używać i które rozwiązanie jest lepsze.

\section{Zakres pracy}
\indent W ramach pracy zrealizowano następujące zagadnienia:
\begin{itemize}
 \item sposób zarządzania warstwą modelu w technologii ADF z użyciem komponentów biznesowych - praca przedstawia przekrój budowy oraz struktury
komponentów biznesowych, na podstawie których można taki szkie\-let wytwo\-rzyć oraz odwzorować w innej aplikacji,
 \item analiza budowy komponentów biznesowych - szczegółowy opis poszczególnych elementów,
 \item opracowanie oraz analiza warstwy modelu w apli\-kacjach z użyciem ADF – zaprezentowanie kolejnych kroków budowania komponentów
w aplikacjach ADF,
 \item porównanie zarządzania z poziomu BC i SQL - część pracy poświęcona jest porównaniom pomiędzy zarządzaniem danymi z poziomu SQL
oraz BC,
 \item wskazanie wad i zalet poszczególnych technologii i podejść - wynikiem porównania podejść będzie wskazanie listy zalet i wad dla
poszczególnych technologii, w zależności od zastosowania i przeznaczenia.
\end{itemize}
Tak zgrupowane zagadnienia w znaczący sposób wyznaczają zakres ni\-niej\-szej pracy i przedstawiają główną tematykę.

\section{Układ pracy}
\indent Praca podzielona jest na rozdziały opisujące poszczególne etapy realizacji tema\-tu pracy. 
W rozdziale pierwszym zawarta jest problematyka oraz zakres pracy. Przedstawiono najważniejsze zagadnienia pracy, jakie
autor przyjął wybiera\-jąc ten temat pracy. \\
W kolejnym rozdziale została zaprezentowana podstawowa terminologia związa\-na z tematem pracy magisterskiej. Rozdział 
zawiera wyjaśnienie podstawowych pojęć tak, aby osoby bez doświadczenia i specjalistycznej wiedzy mogły poznać nową technologię. 
W dalszej kolejności opisane zostały 
pow\-szechne i standardowe rozwiązanie jakim jest Oracle Database oraz istniejące dla niego alternatywy, 
co zostało zaprezentowane w dalszej części pracy. 
Poka\-zano również strukturę technologii oraz zawarto dokładne rozwinięcie tematu pracy. Opisano mocne i słabe strony,
poszczególnych rozwiązań, co pozwoliło na dokonanie porównania danych technologii. \\
Czwarty rozdział zawiera opis części praktycznej pracy. Pokazuje on strukturę za\-rządzania danymi na przykładowej 
aplikacji. Dalsza część rozdziału opisuje również wybrane narzędzia pracy oraz
sposób przeprowadzania testów. \\
Istotną częścią pracy jest rozdział piąty. Zawiera on porównanie, wskaza\-nie wad i zalet poszczególnych rozwiązań. 
Najważniejszym rezultatem pracy jest wskazanie różnic oraz analiza, kiedy dana technologia powinna być stosowana i w jakich sytuacjach
dane rozwiązanie lepiej się sprawdzi.\\
Ostatni rozdział stanowi podsumowanie pracy, opis uzyskanych rezultatów oraz końcowe wnioski. 
W rozdziale tym zostały opisane możliwości dalszych badań wraz z podsumowaniem, w jakim stopniu udało się zrealizować cel pracy. 


\chapter{Terminologia oraz podstawy teoretyczne} \label{rozdz.terminologia}
\indent Poniżej została zaprezentowana podstawowa terminologia związana z technologią ADF stosowaną podczas pisania
pracy. W dalszej części pracy autor będzie używał skrótów, które również zostaną opisane.
\section{Podstawowe definicje}
\indent 
\begin{itemize}
\item \textbf{ADF} - (ang. {\it{Application Development Framework }}) jest to kompletny framework opracowany przez firmę Oracle Corporation. 
Powstał w celu realizacji aplikacji biznesowych implementowanych w języku JAVA. Za\-wiera olbrzymią ilość gotowych rozwiązań oraz 
reużywalnych struktur. Zaimplementowane aplikacje są w pełni zgodne z trójwarstwowym wzor\-cem MVC \cite{bib_adf_handbook, bib_adf_real_world}.
\item \textbf{BC} - (ang. {\it{Business Components }}) jest kluczową strukturą w warstwie mode\-lu dla frameworka ADF. Wyznacza podstawowe określenie
wszystkich elementów dostępu do danych. Stanowi zbiór plików XML oraz klas w języku JAVA używanych do 
implementacji oraz zarządzania danymi dla funkcji biznesowych.
\item \textbf{framework} - kompletny pakiet narzędzi oraz rozwiązań, wprowadzających standaryzację aplikacji. Dostarcza zbiór gotowych oraz
dokładnie opraco\-wanych wzorców, które stosuje się podczas implementacji oprogramowania.

\item \textbf{MVC} - (ang. {\it{Model–View–Controller }}) wzorzec projektowy architektury aplikacji. Model reprezentuje zbiór danych oraz 
logiczną część aplikacji. Warstwa widoku przyjmuje dane od użytkownika oraz ma zadanie przedstawienia interfejsu. 
Warstwa kontrolera stanowi obsługę zachowania użytkownika, reagując na jego akcje, stanowi łącznik pomiędzy wido\-kiem a modelem.
\item \textbf{XML} - (ang. {\it{Extensible Markup Language}}, w wolnym tłumaczeniu Rozszerzalny Język Znaczników) to technologia, której 
przeznaczeniem jest repre\-zentacja struktur danych za pomocą zbioru węzłów (elementów, atrybutów). \\
\item \textbf{SOA} - (ang. {\it{Service Oriented Architecture}}), architektura oparta na usługach. Podejście w programowaniu, w którym nacisk 
został położony na zdefiniowanie usług będących realizacją wymagań użytkowników. Takie podejście daje możliwość lepszego powiązania
biznesowej strony z zasobami informatycznymi \cite{bib_adf_handbook}.
\item \textbf{ADF Faces} - jest biblioteką komponentów graficznych umożliwiającą budowę interfejsu użytkownika w aplikacjach 
bazujących na technologii Java\-Server Faces (JSF). Oferuje ona bogactwo oraz interaktyw\-ność komponentów
ADF Faces. Uzyskane jest to w znacznym stopniu dzięki technologii Ajax. Opracowanie JSF wywołało marginalizację technologii 
ADF Swing wcze\-śniej stosowanych, m. in. gdy wymagana była większa responsywność interfejsu użytkownika niż charakterystyczna 
dla pierwszych aplikacji webowych. Aktualna wersja biblioteki ADF Faces w wersji 11g określana jest mianem ADF Faces Rich Client ze względu 
na ogromne predyspozycje do budowy złożonych aplikacji internetowych (ang. Rich Internet Applications – RIA) \cite{bib_adf_start_guide}.
\item \textbf{ADF Swing} - zbiór bibliotek umożliwiających implementację aplikacji deskto\-powych, obecnie trochę przestarzały i nie używany \cite{bib_adf_start_guide}.
\item \textbf{JavaBeans} - dobrze znany mechanizm wielokrotnego użytkowania klas JAVA, opakowanych w postaci ziarna (ang. {\it{bean}}). 
Charakteryzuje się bezargumentowym konstruktorem. Dostęp do metod oraz właściwości jest możliwy dzięki metodom dostępowym.
\item \textbf{JSF} - (ang. {\it{JavaServer Faces}}), technologia bazująca na języku JAVA framework, umożliwia znaczne uproszczenia podczas
opracowywania interfejsu użyt\-kownika do aplikacji webowych wykonanych w JAVA EE. W chwili obecnej domyślną technologią 
widoku dla stron JSF jest technologia Facelets \cite{bib_adf_start_guide}.
\item \textbf{JSP} - (ang. {\it{JavaServer Pages}}), technologia, która umożliwia opracowa\-nie dynamicznych dokumentów WWW w formatach HTML, XHTML, 
DHTML oraz XML z zastosowaniem języka JAVA, który jest umiejsco\-wiony w kodzie HTML danej strony. Strona JSP w procesie translacji jest 
zamieniana na serwlet \cite{bib_adf_start_guide, bib_adf_cookbook}.
\item \textbf{Struts} -  jest otwartym frameworkiem przeznaczonym dla aplikacji wytwo\-rzo\-nych w języku programowania JAVA. 
Do głównych zastosowań Struts należy prezentowanie danych oraz ich kontrolę. Technologia pozwala w prosty sposób mapować 
adresy stron www aplikacji na odpowiednie metody klas obsługujących żądania. Konfiguracja wywoływania metod znajduje się w pliku XML \cite{bib_adf_cookbook}.
\item \textbf{ADF Bindings} - jest elementem, który udostępnia wiele typów (atrybutów, operacji) umożliwiających dostęp do warstwy logiki 
biznesowej oraz danych. Zachowywana jest dzięki nim struktura MVC w dość prosty sposób, pozwalając na łatwą separację widoku od danych \cite{bib_adf_cookbook}.
\item \textbf{Task flow} - przepływy zadań zapewniające modułowe podejście do defi\-nio\-wania przepływu sterowania w 
aplikacji. Zamiast reprezentować aplikację jako pojedynczy przepływ dużej strony JSF , można
podzielić ją na zbiór przepływów zadań. Węzły w przepływach zadań są określane mianem dzia\-łalności, 
które reprezentują prostą logiczną operację, np. wyświetlenie strony, wykonywanie logiki aplikacji 
lub wywołanie innego przepływu zadań. \\
Przejścia między działaniami nazywane są wywoływaniem przypadku prze\-pływu sterowania.
Przepływy zadania dzielone są na dwie grupy:
\begin{itemize}
 \item bezgraniczny (ang. {\it{unbounded}}) przepływ zadań - zespół działań, kontroli przepływów sterowania oraz klas zarządzających, 
współ\-działających w celu umożliwienia użytkownikowi wykonania zadania,
 \item ograniczony (ang. {\it{bounded}}) przepływ zadań - specjalistyczna forma przepływu zadań. W przeciwieństwie do bezgranicznych 
przepływów zadań, ma jeden punkt wejścia oraz zero lub więcej punktów wyjścia. Zawiera swój własny zestaw reguł 
prywatnych przepływu sterowania i działania. Umożliwia ponowne użycie, opuszczanie i powtórne wejścia do przepływu.
\end{itemize}

\item \textbf{Data controls} - kontrola danych jest łącznikiem umożliwiającym dostęp danych z pewnego źródła i przekazania 
go do interfejsu użytkowni\-ka w aplikacji \cite{bib_adf_cookbook}. 
Najczęściej stosowane rodzaje kontroli danych to:
\begin{itemize}
 \item Business Components Data Control - podstawowy rodzaj dostępu do danych, generowany dla komponentów biznesowych,
 \item JavaBean Data Control - zaimplementowany dostęp dla klasy JAVA,
 \item EJB Data Control - zbiór klas, ziaren udostępniający dostęp do zbioru zasobów,
 \item Web Service Data Control - dostęp do danych udostępnianych przez serwis,
 \item URL Service Data Control - dostęp do danych pochodzących z adresu URL, ten typ jest możliwy jedynie do odczytu strumienia danych.
\end{itemize}

\item \textbf{Binding container} - zbiór zasobów udostępnianych poprzez data controls dla konkretnego zakresu użytkowania.
\item \textbf{Binding context} - określenie kontekstu w jakim uzyskujemy dostęp do danych poprzez data controls.
\end{itemize}
\section{Historia} 
Początki JDevelopera i technologii ADF sięgają roku 1997. Firma Oracle Corporation zaczęła korzystać z licencji na narzędzie JBuilder 
firmy Borland. Nabyła ona prawa do kodu źródłowego JBuilder i zaczęła pracę nad nowym środowiskiem. Pierwsza wersja JDeveloper
w wersji 1.0 była bardzo zbliżona do JBuilder. Z każdą nową wersją różnice pomiędzy tymi dwoma środowiskami były zacierane. 
Nowe wersje JDevelopera i frameworka ADF dostarczały coraz nowszych rozwiązań. Pracowano nad rozwiązaniem pro\-blemu połączenia 
programów pisanych w języku JAVA z relacyjną bazą danych. Komponenty biznesowe pojawiły się w roku 2004. Kolejne wersje poprawiają 
wydajność oraz intuicyjność budowania aplikacji webowych po dzień dzisiejszy \cite{bib_adf_cookbook, bib_adf_guide, bib_doc_adf}. 
\newpage
\section{Application Development Framework} 
ADF to standard, będący solidną, skalowalną oraz bezpieczną platformą. To również podstawa wielu dzisiejszych aplikacji korporacyjnych. 
Technologia dostarcza ze\-staw specyfikacji dla budowania wielowarstwowych aplikacji za pomocą języka JAVA. Pojawienie się Oracle ADF zapewnia realizację 
niezwykle rozbudowanych i zaawansowanych aplikacji z zastosowaniem wzorców projektowych ze zmniej\-szonym wysiłkiem. Zwiększenie zapotrzebowań
na budowę aplikacji kompozytowych wy\-korzystujących SOA zmusiło deweloperów do implementacji aplikacji, które będą w dużej mierze zwinne. ADF
jest technologią, która w wielkim stopniu ułatwia ten proces. Gwarantuje solidne oraz wydajne środowisko do implementacji aplikacji.\\
\subsection{Wprowadzenie}
ADF koncentruje się na wszystkich warstwach MVC. Oferuje zintegrowane roz\-wiązania obejmujące przekrój całej aplikacji. Daje możliwość 
zarówno trwałości
danych, reużywalną warstwę kontrolera oraz bogaty interfejs wiązania danych z warstwy modelu wprost do warstwy widoku. Umożliwia łatwe rozwijanie
aplikacji pod kątem interfejsów realizujących logikę oraz wymagania biznesowe. Przekrój dla wszystkich warstw oraz używanych technologii znajduje
się na rysunku \ref{fig.schemat_adf}. 

\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth]{picture/adf_architecture.jpg}
\caption{Technologie oraz architektura ADF.} [Źródło: {\em http://imdjkoch.files.wordpress.com/2012/04/adf-1architecture.jpg}]
\label{fig.schemat_adf}
\end{figure} 
Na rysunku \ref{fig.schemat_adf} można zaobserwować 
zastosowane rozwiązania dla aplikacji webowych jak i dla aplikacji desktopowych. 
Widoczne jest również, gdzie w strukturze znajdują się komponenty biznesowe (ADF\-bc). Stanowią główny element realizujący logikę biznesową oraz
pośredniczący w odczycie danych z różnego typu źródeł.\\
Programiści mogą wybrać różne technologie do realizacji każdej z warstw aplikacji zachowując separację poszczególnych warstw. Te same metody
mogą zostać zrealizowane za pomocą ADF Swing bazujących na komponentach biznesowych jak aplikacje na podstawie ADF Faces i JavaBeans.
Dowolność wyboru jest głównym mottem firmy Oracle. Deweloperzy mogą w znacznym stopniu wybrać swój styl (deklaratywny, wizualny, kodowany).
Framework umożliwia programistom używanie różnych umiejętności oraz metod współ\-pracy w ramach tego samego projektu.
Udostępniony wybór w pełni potwierdza możliwości uzyskane przez taki różnorodny zbiór technologii. 
\subsection{Architektura MVC}
W kolejnych podrozdziałach znajduje się bardziej szczegółowy podział oraz opis struktury MVC. Rysunek \ref{fig.schemat_mvc} przedstawia rozmieszczenie
poszczególnych warstw oraz powiązania. Autor opisał odniesienie każdej z tych warstw do technologii ADF, przedstawiajac dzięki 
temu konkretne użycie warstw \cite{bib_adf_made_sample}.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.65\textwidth]{picture/mvc.png}
\caption{Struktura MVC.} [Źródło: {\em http://docs.oracle.com/cd/E16162\_01/web.1112/e16182/toc.htm}]
\label{fig.schemat_mvc}
\end{figure} 
\subsubsection{Warstwa widoku}
ADF Faces jest zbiorem standardów komponentów JSF, która posiada funkcjo\-nal\-ność AJAX.\\ 
AJAX jest kombinacją ogromnego zbioru technologii takich jak:
\begin{itemize}
 \item JavaScript,
\item dynamiczny HTML (DHTML),
\item XML,
\item XmlHttpRequest.
\end{itemize}
ADF Faces udostępnia możliwość komunikacji z serwerem bez przeładowywania strony. 
Od kiedy AJAX udostępnił możliwość używania standardów technologii internetowej dla aplikacji klienckich, 
JSF wprowadziły kontrolę po stronie serwera, redukując generowanie żądań JavaScript, które
dość często występują w typowych aplikacjach AJAX. 
Osiągniecie kompatybilności wizual\-nej umożliwia użycie poprzez komponenty ADF Faces 
narzędzi oraz mechanizmów renderowania, które zarządzają wyświetlaniem interfejsów oraz udostępniają 
obiekty JavaScript potrzebne do osiągnięcia pełnej funkcjo\-nalności oraz zarządzania wyświetlanymi elementami \cite{bib_adf_ajax}.
ADF Faces wprowadza ponad 150 komponentów. Podział komponentów widoczny jest na rysunku \ref{fig.components}.

\begin{figure}[h!]
    \centering
  \includegraphics[angle = 90, width=1.1\textwidth, height = 1.27\textwidth]{picture/components_diagram2.png}
\caption{Struktura komponentów warstwy widoku.} [Źródło: {\em http://2.bp.blogspot.com}]
\label{fig.components}
\end{figure} 


W grupie komponentów zawierają się hierarchiczne relacje pomiędzy kontrolką typu input (UIInput) a kontrolkami pochodnymi
(UISelectOne, UISelectMany, UISelectBoolean), kolumny z danymi (UIColumn), panele otaczające (UIForm, UIPanel)
oraz wiele innych elementów będących podstawowymi elementami stron jak przyciski (UICommand) czy pola tekstowe(UIOutput). W warstwie widoku
istnieje również dostęp do wielu gotowych elementów graficznych i wizualizujących takich jak dynamiczne grafy, wykresy oraz wiele
innych wyma\-gających wyświetlania danych oraz ich wizuali\-zacji w trybie rzeczywistym. Dla każdego z tych elementów istnieje 
wsparcie dla odpowie\-dniej konfiguracji oraz  dostosowania wyglądu elementów, dopasowując każdy z nich do indywidualnych potrzeb. \\

ADF Faces może być również używany w aplikacjach posługujących się  
biblio\-teką Facelates. Jest to scentralizowana w kierunku JSF, zdefiniowana za pomocą języka XML technologia, która
wprowadza alternatywę w użyciu silnika JSP. \\ Wszystkie te rozwiązania sprawiają, że istnieje szereg
alternatywnych sposobów na skonstruowanie interfejsu użytkownika.

\subsubsection{Warstwa kontrolera}
Warstwa kontrolera służy do zarządzania oraz obsługi przejść pomiędzy stro\-nami w aplikacji. Kontroler ADF wprowadza
wzmocnioną nawigację oraz zarzą\-dzanie modelem przekazując go do warstwy interfejsu. Do dyspozycji jest deklaratywna
realizacja zbioru przejść oraz zadań (ang. {\it{task flows}}) gdzie możliwe jest przekazywanie sterowania aplikacji 
pomiędzy różnymi typami aktywności. \\
\newpage
\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth]{picture/beans.png}
\caption{Zakres beanów.} [Źródło: {\em http://docs.oracle.com/cd/E15051\_01/web.1111/b31974/adf\_lifecycle.htm}]
\label{fig.beans}
\end{figure} \newpage
Typy pomiędzy jakimi mogą następować przejścia, obejmują:
\begin{itemize}
\item strony,
\item metody (zarówno w beanach jak i modelu),
\item warunki logiczne,
\item inne przepływy przejść.
\end{itemize}
Każdy z takich przepływów przejść może być oczywiście reużywalny i grupo\-wany w szablony, co sprawia, że rozwiązania stają się bardziej
generyczne oraz uniwersalne. \\
Ważne elementy kontrolera ADF stanowią wspomniane już beany będące grupą klas JAVA. Każda z takich klas zdefiniowana jest 
czasem życia, który defi\-niuje dostęp do zasobów jakie udostępnia dana klasa. Czas życia klas w kontrolerze widać na rys. \ref{fig.beans}.
Zakres życia dzielony jest na:
\begin{itemize}
\item \textbf{backing scope} - klasa mająca zwykle najkrótszy czas życia, instancja beana powinna być utworzona jedynie w celu wywołania operacji,
\item \textbf{request scope} - klasa inicjalizowana jest od nowa przy każdym żądaniu wysyłanym przez użytkownika do serwera, 
podobnie jak backing scope nie powinna być używana do przechowywania danych,
\item \textbf{view scope} - klasa JAVA istniejąca podczas wyświe\-tlania jednego wido\-ku, przy każdej zmianie inicjalizowana jest od nowa, przechowuje 
informacje, które nie powinny być dostępne na innych stronach, a mają istnieć podczas wyświe\-tlania konkretnego widoku,
\item \textbf{page flow scope} - zawiera metody oraz dane, które powinny być dostęp\-ne po\-między stronami, jest odpowiednia 
do przekazywania informacji pomiędzy widokami oraz przekazywania parametrów,
\item \textbf{session scope} - każda instancja beana istnieje w ciągu czasu życia sesji użyt\-kownika, podczas używania tego zakresu życia trzeba pamiętać 
o kontroli istnienia, 
\item \textbf{application scope} - wspólna instancja dla całej aplikacji, zwykle uży\-teczna dla aplikacji webowych, pozwalająca 
zgrupować dane, zwykle stałe, wspólne dla wszystkich użytkowników.
\end{itemize}
Wszystkie rozwiązania wprowadzone przez firmę Oracle Corporation pozwalają na prostszą implementację oprogramowania oraz dużo łatwiejsze zarządzanie 
pomiędzy danymi znaj\-dującymi się w modelu a reprezentacją interfejsu dla użytkownika.

\subsubsection{Warstwa modelu}
Warstwa modelu ADF ekstrahuje implementację usług biznesowych i dostępu do danych. Wprowadza pojedyncze, programistyczne interfejsy 
dla różnych typów danych i usług.
Wystawione interfejsy opisują możliwości oraz ope\-racje, jakie wystawia serwis dostępu do danych.
Dzięki nim możliwe jest użycie kolekcji danych wraz z informacjami o typach oraz metodach związanych z konkretnymi typami danych.
Model odczytuje informacje opisujące użyte metody kontroli danych zapisując wszystko w plikach XML. Implementuje 
również połączenie w dwie strony pomiędzy interfejsem użytkownika a warstwą biznesową \cite{bib_adf_xml}.\\
Na rys. \ref{fig.bussiness_service} widać schemat elementów komunikujących się z warstwą mode\-lu, jak również budowę takiej warstwy.
Zbudowana jest ona na podstawie struktury hierarchicznej. W opracowanym kontekście jest dostęp do zbioru powiązanych usług i danych, 
które uzyskują informacje przy pomocy struktur kontrolujących dostępność usług biznesowych.
\begin{figure}[h!]
    \centering
  \includegraphics[width=1.00\textwidth]{picture/bussiness_service.png}
\caption{Hierarchiczna struktura warstwy modelu.} [Źródło: {\em http://docs.oracle.com/cd/B15897\_01/web.1012/b14362/img/adfbc1.gif}]
\label{fig.bussiness_service}
\end{figure} 

Dostęp do usług biznesowych z warstwy modelu uzyskać można za pomocą:
\begin{itemize}
 \item \textbf{powiązanych obiektów} (ang. {\it{binding context object}}) - grupa definicji oraz wspólna przestrzeń nazw dla używających je aplikacji klienckich, pozwalająca
wszystkim obiektom mode\-lu na wygodne ich wystawienie, każda aplikacja webowa oraz desktopowa rejestruje kontekst używając definicji zmiennych;

\item \textbf{interfejsów kontroli danych} (ang. {\it{data control interfaces}}) - aplikacje klienckie wystawiające grupę interfejsów 
dających dostęp do modelu, gdzie jeden z takich interfejsów jest wymagany do utworzenia pośrednika pomiędzy obiektami modelu 
dla każdej konfiguracji usług biznesowych;

\item \textbf{powiązanych kontenerów obiektów} (ang. {\it{binding container objects}}) - definiuje kontener dla powiązanych obiektów, 
zawierając iteratory oraz obiekty kontroli. 
Inicjalizacja instancji kontenera ma miejsce dla każdej strony lub panelu JAVA, z możliwością ponownego użycia obiektów 
na wielu stronach z tymi samymi danymi, które są współdzielone pomiędzy nimi. Kontener pozwala na zde\-finiowanie, czy dana strona 
albo panel będzie w trybie edycji lub tylko podglądu danych;

\item \textbf{powiązanych iteratorów obiektów} (ang. {\it{iterator binding objects}}) - jeden z składowych elementów kontenera, używany 
do przechwytywania wydarzeń generowanych
z połączonych usług biznesowych, wysyła bieżące wiersze do konkretnych elementów wyświetlających aktualny zakres danych,
umożliwia wiele operacji ograniczania oraz rozszerzania ilości danych pobieranych z modelu i przekazywanych do wyświetlenia;

\item \textbf{powiązanych obiektów kontroli} (ang. {\it{control binding objects}}) - definiu\-ją sposób wyświetlania elementów strony realizując 
odzwierciedlenie modelu. Określają rodzaj elementu zasilającego interfejs w dane, pozwalając na ich wygodne użycie;

\item \textbf{powiązanych obiektów akcji} (ang. {\it{action binding objects}}) - pozwalają na udostępnianie operacji wykonywanych bezpośrednio na modelu, w łatwy sposób można uzyskać dostęp do 
operacji np. do zatwierdzania czy wycofywania zmian na danych, oraz ich prostej selekcji;
\end{itemize}

\subsubsection{Warstwa biznesowa}

Warstwa biznesowa jest ściśle powiązana z warstwą modelu. Implementacja logiki biznesowej realizowana jest w jednym lub więcej serwisów biznesowych,
oferujących usługi dla aplikacji. Klienckie aplikacje używają wystawionych interfejsów, dzięki którym mają dostęp do dodawania, usuwania i 
zmieniania danych. W dużej mierze niniejsza praca opisuje budowę oraz implementację warstwy biznesowej, dlatego poniżej znajdują się jedynie podstawowe
informacje o najważniejszych komponentach biznesowych, których dokładny opis znajduje się w dalszej części pracy.\\
Do najważniejszych komponentów biznesowych należy zaliczyć:
\begin{itemize}
 \item Entity Object - obiekt encji reprezentuje wiersze w bazie danych,
pozwa\-lając na ich prostą edycję. Pozwala na enkapsulację logiki biznesowej, aby mieć pewność 
przynależności odpowiednich reguł dla konkretnego zbioru danych. Posiada relacje pomiędzy obiektami w bazie określane mianem asocjacji.
\item View Object - obiekt widoku, który reprezentuje zapytania SQL. Wynik takich zapytań stanowi źródło danych, które może zostać
łączone, filtrowane, sortowane tak, aby zmienić je do odpowiedniej formy, która zostanie zaprezentowana użytkownikowi systemu.
Zawiera linki łączące widoki, po\-zwalając na utworzenie połączeń relacji master-detail, których nie ma zde\-finiowanych w bazie danych.
\item Application Module - instancja takiego modułu zawiera w sobie zbiory encji i widoków zgrupowane dla reprezentacji grupy logiki biznesowej.
Każda instancja działa niezależnie od pozostałych.
\end{itemize}

\subsection{Zastosowanie frameworka}
Najważniejszym zastosowaniem Oracle ADF jest implementacja aplikacji trój\-warstwowych, 
które wymagają swobodnego ekstrahowania poszczególnych 
\newline warstw. Upra\-szcza on standardy 
JAVA Platform Enterprise Edition tak, aby ułatwić i przy\-spieszyć wdrażanie aplikacji zorientowanych na usługi. \\

Oracle ADF ułatwia implementację oprogramowania minimalizując potrze\-bę pisania kodu, który
w aplikacji realizuje infrastrukturę, pozwalając programistom skupić się na funkcjach 
biznesowych realizowanych przez system. Technologia koncentruje się na zapewnieniu wizualnego 
oraz deklaratywnego po\-dejścia poprzez użycie rozbudowanych na\-rzędzi, czego przykładem jest JDeveloper. Ze względu na 
duży zbiór zastosowanych rozwiązań, można go stosować dla aplikacji webowych i dekstopowych. 

\subsection{Wzorce projektowe}\label{label.patterns}
Lista zaimplementowanych wzorców i zasad projektowych w ADF oraz sposób ich implementacji zostały przedstawione w postaci 
tabeli \ref{tabela.pattern_list} \cite{bib_adf_guide, bib_doc_adf}. 
Oprócz standar\-dowego i podstawowego rozwiązania MVC istnieje duża liczba innych rozwiązań, którch używają projektanci.
%http://docs.oracle.com/cd/E16162_01/web.1112/e16182/appendix_designpat.htm#sm0421

\begin{center}
\begin{longtable}{|C|L|L|}
\caption{Opis realizowanych rozwiązań w ADF \cite{bib_adf_guide, bib_doc_adf}. } \label{tabela.pattern_list} \\

\hline \multicolumn{1}{|c|}{\textbf{Zasada}} & \multicolumn{1}{L|}{\textbf{Opis}} & \multicolumn{1}{L|}{\textbf{Realizacja}} \\ \hline 
\endfirsthead

\multicolumn{3}{c}%
{{ \tablename\ \thetable{} Opis realizowanych rozwiązań w ADF \cite{bib_adf_guide, bib_doc_adf}.}} \\
%{{\bfseries \tablename\ \thetable{} -- ciąg dalszy tabeli}} \\

\hline \multicolumn{1}{|C|}{\textbf{Zasada}} & \multicolumn{1}{L|}{\textbf{Opis}} & \multicolumn{1}{L|}{\textbf{Realizacja}} \\ \hline 
\endhead

%\hline \multicolumn{3}{|r|}{{Ciąg dalszy na następnej stronie}} \\ \hline
\endfoot

\hline \hline
\endlastfoot
Model - View - Controller & Prosty sposób na separację danych od interfejsu. & Realizacja modelu MVC odbywa się 
poprzez wystawienie danych oraz usług dla pozostałych części systemu oraz serwisów. 
Framework sam dba o rozdzielenie warstwy widoku oraz kontrolera od dostępu do danych i logiki biznesowej.  \\ \hline

Interface / Implementation Separation & Separacja wystawionego API oraz jej implementacji.
& Komponenty biznesowe wymuszają logiczne oddzielenie warstwy klienta oraz dostępnej funkcjonalności od jej realizacji. 
Interfejsy są generowane automatycznie i reagują na zmianę istniejącej funkcjonalności. \\ \hline

Service Locator & Streszczenie szczegółów technicznych serwisów tak, aby obiekt klienta miał do nich łatwiejszy dostęp.
& Moduły ADF używają prostych konfiguracyjnych obiektów, które pozwalają na ukrycie niskopoziomowych
informacji oraz mechanizmu zarządzania pulą modułów.  \\ \hline

Inversion of Control & Odwrócenie sterowania, wyniesienie kontroli wybranych elementów na zewnątrz komponentu.
& Możliwość nadpisania metod, które wywoływane są w miarę potrzeb podczas przetwarzania. \\ \hline

Dependency Injection & Wstrzykiwanie zależności, zwiększa konfigurowalność oraz elastyczność kontenera.
& Konfiguracja bazująca na plikach XML na podstawie, których framework sam dokonuje wstrzyknięć zależnych obiektów. \\ \hline

Active Record & Opakowanie obiektów bazodanowych, dodając logikę, pozwala na hermetyzację dostępu do danych.
& Wsparcie mapowania uwzględniającego asocjacje, kompozycję i dziedziczenie. \\ \hline

Data Access Objects & Jednolity sposób komunikacji z źródłem danych, aplikacja nie musi znać sposobu dostępu do danych.
& Automatyczna implementacja dostępu do różnych typów danych, zarówno do odczytu jak i do edycji. \\ \hline

Session Facade & Zapobiega nieefektywnemu dostępowi oraz nieumyślnej ekspozycji informacji biznesowych.
& Moduły aplikacji automatycznie implementują wzorzec fasady w każdym z obsługiwanych trybów ich wdrażania. \\ \hline

Value Object & Wydzielenie grupy obiektów o wspólnym sposobie przesyłania danych. 
& Dowolność w stosowaniu typów generycznych lub konkretnych implementacji typu generycznego. \\ \hline

Page-by-Page Iterator & Zapobiega przesyłaniu niepotrzebnych danych do klienta dzieląc dane na fragmenty. 
& Zarządzanie ilością wyświetlanych wierszy w jednym czasie oraz nakładanie ograniczeń na liczbę uzyskiwanych 
rekordów w jednym czasie. \\ \hline

Fast-Lane Reader & Użycie API JDBC bezpośrednio w uzyskiwaniu danych tylko do odczytu. 
& Zwiększenie wydajności dla części zapytań tylko do odczytu. Kojarzenie obiektów 
z encjami umożliwia wykonywanie zapytań bez zwiększonych wymagań \cite{bib_adf_jdbc}.   \\ \hline

(Bean) Factory & Inicjalizacja instancji oraz konfiguracja w czasie rzeczywistym działania aplikacji. 
& Inicjalizacja obiektów na podstawie metadanych XML oraz klasy „fabryki” umożliwiając lepsze dostosowanie aplikacji. \\ \hline

Entity Facade & Restrykcyjny dostęp do danych dla jednej lub więcej encji. 
& Możliwość uzyskiwania danych z kombinacji obiektów poprzez jeden wspólny obiekt. \\ \hline

Value Messenger & Zachowanie synchronizacji z warstwą pośrednią. 
& Synchronizacja danych znajdująca się w pamięci po stronie klienta oraz ich aktualizacja. \\ \hline

Continuations & Zwiększenie skalowalności dostępu do warstwy modelu. 
& Zarządzanie stanami modułów aplikacji oraz ich pulą. Zmniejszenie potrzebnych zasobów oraz 
optymalizacja na podstawie zdefiniowanych i dopasowanych parametrów.  \\ \hline

\end{longtable}
\end{center}

\section{Komponenty biznesowe - Business Components}

Podczas budowy aplikacji zorientowanej na usługi, należy pamiętać o zaimplementowaniu logiki biznesowej jako jednego
lub więcej serwisów biznesowych. 
Serwisy takie umożliwiają klientom opracowywanie zapytań, aktualizację oraz usuwanie rekordów z bazy. 
Oracle ADF dostarcza komponenty, które ułatwiają implementację serwisów biznesowych opartych na bazie danych.
\subsection{Struktura BC}
Na rysunku \ref{fig.schemat_bc} widać strukturę komponentów biznesowych. Najważniejszy z nich to moduł aplikacji (ApplicationModule). 
Jest on komponentem transakcyjnym, który klienci UI (User Interface) używają do pracy z danymi. 
Definiu\-je model danych, który można aktualizować poprzez procedury i funkcje, nazywane metodami 
serwisowymi. Komponent biznesowy używany jest do prze\-glądania i zmiany danych. Używa widoków (ViewObject) 
w swoim modelu danych. 
\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth]{picture/bc_architecture.png}
\caption{Zależności pomiędzy koponentami biznesowymi.} [Źródło: {\em http://4.bp.blogspot.com/\_Y8eLenGvPHg/TQ0LAEGcOXI/AAAAAAA
AAaA/c3qa4gfRq70/s1600/beginning\_of\_eovo.gif}]
\label{fig.schemat_bc}
\end{figure} 
Widoki stanowią reprezentację zapytań w języku SQL i ułatwiają pracę z wynikami tych zapytań. 
Komponent biznesowy umożliwia używanie całego przekroju możliwości języka SQL: łączenia, filtrowania, sortowania i formowania danych
dla interfejsu użytkownika. Istnieje możliwość integrowania kilku komponentów w jeden lub scalania ich 
w relację główny-szczegółowy poprzez linki. Kiedy użytkownik modyfikuje dane w interfejsie użytkownika, 
widoki współpracują z encjami, aby zachować zmiany i zapisać dane.
Widoki bazują na encjach, czyli komponentach odnoszących się do tabel. Odpowiednikiem wiersza w tabeli 
jest obiekt Row. Ułatwia modyfikację tych danych poprzez obsługę wszystkich operacji DML oraz udostępnia
metody napisane w języku JAVA reprezentujące dodawanie, modyfikację i usuwanie wierszy. Metody obejmują w ten 
sposób logikę biznesową dla wiersza.

\subsection{Odzwierciedlenie komponentów}
Poniżej w tabeli \ref{tabela.mapowanie} znajduje się zestawienie odpowiedników pomiędzy obiektami w języku SQL i ADF. 
\begin{center}
\begin{longtable}{|L|L|}
\caption{Odzwierciedlenie obiektów w SQL i BC. } \label{tabela.mapowanie} \\

\hline \multicolumn{1}{|L|}{\textbf{SQL}} & \multicolumn{1}{L|}{\textbf{BC}} \\ \hline 
\endfirsthead

\multicolumn{2}{c}%
%{{\bfseries \tablename\ \thetable{} -- ciąg dalszy tabeli}} \\
{{ \tablename\ \thetable{} Odzwierciedlenie obiektów w SQL i BC.}} \\
\hline \multicolumn{1}{|L|}{\textbf{SQL}} & \multicolumn{1}{L|}{\textbf{BC}}  \\ \hline 
\endhead

%\hline \multicolumn{2}{|r|}{{Ciąg dalszy na następnej stronie}} \\ \hline
\endfoot

\hline \hline
\endlastfoot
Funkcje, procedury, wyzwalacze &  Moduł aplikacji (AM) \\ \hline
Tabele &  Encje(EO) \\ \hline
Klucze &  Asocjacje \\ \hline
Zapytania SQL, widoki &  Widoki(VO) \\ \hline
Łączenia pomiędzy atrybutami, sztuczne klucze &  Linki\\ \hline

\end{longtable}
\end{center}

ADF umożliwia zebranie odwołań do tabel oraz widoków w jedną biznesową całość, dając możliwość uzupełnienia jej w metody  
realizujące wymagania biznesowe. Dzięki temu jest równorzędnym sposobem na dostęp do danych w stosunku do języka SQL.


\chapter{Zarządzanie danymi w Oracle Database} \label{rozdz.metody}
W dalszej części pracy znajduje się krótkie wprowadzenie do architektury Oracle Databases.
Autor w dalszej części pracy odwołuje się do pojęć związanych z zarządzaniem danymi w rowiązaniu Oracle Corporation. 
Dzięki temu czytelnik powinien dostrzec podobieństwa i różnice wynikające z odzwierciedlenia obiekt 
w SQL i BC oraz w mechanizmach zarządzania sesjami i instancjami. 
\section{Architektura bazy danych Oracle}

Baza danych, czyli zbiór danych zapisanych w ściśle określony sposób w strukturach odpowiadających założonemu 
modelowi danych wymaga odpowiedniego sposobu zarządzania. System  RDBMS (ang. {\it{Relational Database Management System}}) 
czyli system zarządzania relacyjną bazą danych to zestaw programów służących do korzystania z bazy danych opartej na 
modelu relacyjnym \cite{bib_oracle_database}. Obej\-muje on dane wraz z wyspecjalizowanym komputerowym  programem do gromadzenia i przetwarzania danych. 
Baza danych jest złożona z wielu różnych elementów. Najważniejszym z nich jest rekord podzielony na kilka pól, w których 
są przechowywane informacje poszczególnych kategorii.  W każdym polu zapisywane są dane dla innej kategorii. 
Dzięki temu możliwe jest szyb\-kie sortowanie rekordów według poszczególnych kategorii lub wyszukiwanie informacji tylko w obrębie  
wybranych pól. Duża liczba systemów zarządzania bazami danych oferuje możliwość implementacji masek wprowadzania danych, 
służących do bardziej wygodnego wprowadzenia nowych informacji zastępując wpisywanie danych w postaci tabelarycznej.

\subsection{Instancja i SGA}
Przy pomocy systemu operacyjnego możliwy jest dostęp do bazy danych, która przechowuje dane w plikach na dysku twardym.
Umożliwienie efektywnego operowanie danymi, możliwe jest dzięki używaniu pamięci współdzielonej
nazywanej Globalnym Obszarem Współdzielonym (ang. {\it{System Global Area}}). Pa\-mięć ta udostępniona 
jest dla wszystkich użytkowników bazy danych.
\newline
Każda instancja Oracle posiada uruchomione procesy w tle oraz zalokowany globalny współdzielony obszar SGA. Użytkownik podłączający 
się do bazy danych, nie uzyskuje danych wprost z pliku bazy danych. Zapytanie języka SQL wykonane przez użytkownika trafia 
do odpowiedniego bufora w strukturze SGA, gdzie następnie, po jego przetworzeniu i zanalizowaniu, pobierane są bloki z pliku 
danych do obszaru SGA. Tak przygotowane informacje są dopiero przekierowane do użytkownika. W kolejnej próbie uzyskania tych 
danych, które znajdują się już w obszarze SGA, pomijany jest krok pobierania danych z pliku i od razu informacja zwracana 
jest użytkownikowi. Relacyjna baza danych Oracle posługuje się standardowym językiem zapytań SQL, oraz posia\-da wbudowany 
wewnętrzny język tworzenia procedur składowanych PL/SQL. 

\subsection{Sesja i transakcje}
Możliwość równoczesnego dostępu do tej samej bazy danych Oracle uzyskuje się dzię\-ki architekturze klient-serwer. 
Same operacje odczytu tych samych danych przez wielu użytkowników równocześnie nie powodują naturalnie konfliktów 
czy niespójności. Konflikt powstaje w przypadku modyfikacji tych samych danych. Istnieje ryzyko wystąpienia niespójności 
tych danych. W celu zachowania spójności danych w czasie równoczesnej próby ich modyfikacji, wpro\-wadzono mechanizm transakcji, 
w ramach której użytkownicy wykonują swoje operacje w bazie danych. Transakcja jest jednostką interakcji 
użytkownika z bazą danych i składa się z pojedynczych zadań realizowanych w bazie danych. W sytuacjach spornych system 
zarządzania bazą danych ustawia o\-peracje różnych transakcji w taki sposób, aby nie powstały niespójności danych. Każde 
podłączenie się użytkownika do bazy danych stanowi rozpoczęcie sesji danego użytkownika. Kończy się ona w momencie 
zakończenia pracy z bazą danych przez użytkownika. Użytkownik może mieć otwartą więcej niż 
pojednczą sesję. Każda z tych sesji daje użytkownikowi możliwość realizacji dowolonej ilości transakcji, jedna po 
drugiej. Użytkownik reali\-zuje swoje transakcje albo przez polecenia języka SQL, które wykonywane są bezpośrednio w 
systemie zarządzania bazą danych lub pośrednio przy użyciu wcześniej przygotowanych aplikacji bazy danych, odwołujących się do DBMS.

\subsection{Mechanizm blokowania danych}
Transakcje, które wykonują operacje odczytu nie maja wpływu  na siebie. Ich działania nie kolidują pomiędzy sobą. 
Sytuacja sporna pojawia się w przypadku operacji zmieniających dane w bazie. Oczywiście jeśli dwóch użytkowni\-ków zmienia 
jednocześnie dwa różne obiekty w bazie danych, nie wywołuje to konfliktu. Jeśli jednak te dwie operacje dotyczą tego samego 
obiektu, mogą powodować sytuacje konfliktowe. Aby uniknąć takich sytuacji oraz zakle\-szczeń, Oracle opracował złożony mechanizm 
zakładania blokad na obiekty. Rozpoczęcie transakcji przez pierwszego użytkownika powoduje, że drugi użyt\-kownik może 
odczytywać dane właśnie modyfikowane przez pierwszego, ale nie może już ich zmodyfikować do czasu zakończenia transakcji 
pierwszego użytkownika. Żądanie drugiego użytkownika do uzyskania zasobów zostanie usta\-wione w kolejce, gdzie będzie oczekiwać na wykonanie.

\subsection{Użytkownicy i schematy}
Kiedy użytkownik bazy danych inicjalizuje obiekt, sprawia, że jednocześnie staje się jego właścicielem. 
Schemat użytkownika stanowi jego logiczną przes\-trzeń baz danych, zawierającą grupę zdefiniowaych przez niego obiektów. Sche\-mat użytkownika 
generowany jest automatycznie podczas jego definiowania, posiadającą unikalną nazwę, która jest 
identyczna z nazwą użytkownika. Ta unikalna nazwa schematu używana jest do wskazania obiektów bazy danych 
stanowią\-cych własność danego użytkownika. \newline
Każda nazwa obiektu musi być unikalna w obrębie oddzielnego schematu. Dozwolone jest natomiast posiadanie przez 
dwóch różnych użytkowników obiektów o tej samej nazwie w swoich schematach, natomiast różny sposób będą realizowane odwoływania.

\subsection{Obiekty bazy danych}
W bazie danych Oracle istnieje wiele różnych obiektów używanych zarówno do przechowywania danych, jak i pełniących 
funkcje pozwalające na zarządzanie danymi. Każdy z takich obiektów utworzony jest przez użytkownika bazy danych 
posiadający odpowiednie uprawnienia do wykonania takiej operacji. Poniżej zostały wypisane podstawowe obiekty 
w systemach Oracle, które można zdefiniować:
\begin{itemize}
 \item tabele - służą do przechowywania danych,
 \item widoki - to logiczna struktura, bazująca na zapytaniu SQL, umożliwia dostęp do podzbioru kolumn i wierszy z wielu tabel,
 \item indeksy - są strukturami danych zwiększającymi prędkość wykonywania operacji na tabeli poprzez zdefiniowanie informacji o atrybucie,
 \item klastry - struktura organizacyjna bloków,
 \item segmenty wycofania - przechowują dane z przed ich zmodyfikowania przez nie zatwierdzona,
 \item tabele tymczasowe - służą do przechowywania danych potrzebnych na czas jednej transakcji lub jednej sesji,
 \item sekwencje - obiekt bazy danych generujący kolejne wartości, używane zwykle przy nadawaniu wartości kluczy,
 \item wyzwalacz - jest to procedura wykonywana automatycznie jako reakcja na pewne zdarzenia w tabeli bazy danych,
 \item pakiety, procedury i funkcje - służące do definiowania akcji na danych.
\end{itemize}

\section{Zarządzanie z poziomu Oracle SQL}

Język zapytań SQL używany do dodawania, modyfikowania baz danych oraz pobierania danych z baz danych. 
Język SQL jest językiem deklaratywnym. Decyzja o sposobie przechowywania i pobrania danych zależna 
jest od systemu zarządzania danymi, jednak w większości systemach zapytania dzielone są na trzy główne podzbiory: 
\begin{itemize}
 \item SQL DML - (ang. {\it{Data Manipulation Language}}) język manipulacji danymi,
 \item SQL DDL - (ang. {\it{Data Definition Language}}) język definicji danych,
 \item SQL DCL - (ang. {\it{Data Control Language}}) język kontroli nad danymi.
\end{itemize}

\subsubsection{DML}
DML służy do wykonywania operacji na danych czyli do ich umieszczania w bazie, kasowania, przeglądania, zmiany. 
Najważniejsze polecenia z tego zbioru to:
\begin{itemize}
 \item SELECT – pobranie danych z bazy,
 \item INSERT – umieszczenie danych w bazie,
 \item UPDATE – zmiana danych,
 \item DELETE – usunięcie danych z bazy.
\end{itemize}

\subsubsection{DDL}
Dzięki DDL można operować na strukturach, w których dane są przechowywane. 
Najważniejsze polecenia tej grupy to:
\begin{itemize}
 \item CREATE (np. CREATE TABLE, CREATE DATABASE, itp.) – utworze\-nie struktury (bazy, tabeli, indeksu),
 \item DROP (np. DROP TABLE, DROP DATABASE, itp.) – usunięcie struktury,
 \item ALTER (np. ALTER TABLE ADD COLUMN, itp.) – zmiana struktury (dodanie kolumny do tabeli, zmiana typu danych w kolumnie tabeli).
\end{itemize}

\subsubsection{DCL}
DCL ma zastosowanie do nadawania uprawnień do obiektów bazodanowych. 
Najważniejsze polecenia w tej grupie to:
\begin{itemize}
 \item GRANT – przyznawanie użytkownikowi praw do obiektów oraz wykonywania operacji na nich,
 \item REVOKE - cofanie użytkownikowi wszystkich praw, które zostały przyznane poleceniem GRANT,
 \item DENY - zabieranie uprawnień.
\end{itemize}
\newpage

\section{Mapowanie do BC-ADF}

Typowe działanie przy implementacji aplikacji ADF z użyciem komponentów biznesowych
polega na utworzeniu obiektów encyjnych oraz asocjacji dla tych obiektów. Tworzone
są obiekty perspektyw, które mogą korzystać z przygotowanych obiektów encyjnych. Całości dopełniają 
moduły aplikacji, które stanowią interfejs dla klientów. Automatycznie wygenerowane są kontrolki 
danych, które zapewniają współpracę z takimi komponentami jak elementy interfejsu użytkownika.

\begin{figure}[h!]
    \centering
  \includegraphics[width=0.92\textwidth]{picture/adfbc.png}
\caption{Struktura BC.} [Źródło: {\em http://docs.oracle.com/cd/E16162\_01/web.1112/e16182/toc.htm}]
\label{fig.schemat_bc1}
\end{figure} 

Wśród oferowanych funkcji należy wyróżnić:
\begin{itemize}
 \item automatyczne zarządzanie odwzorowaniem obiektowo-relacyjnym,
 \item obsługę transakcji,
 \item definiowanie złożonych zapytań SQL,
 \item dostęp do procedur składowanych,
 \item implementację złożonego przetwarzania logiki biznesowej,
 \item definiowanie deklaratywnych reguł poprawności,
 \item obsługę list wartości.
\end{itemize}

Na rys. \ref{fig.schemat_bc1} widać odwzorowanie tabeli na encję OrdersEO posiadającą dwa widoki wskazujące na nią (OrderInfoVO, 
OrdersVO). Encja bazuje na tabeli bazodanowej ORDERS. Wszystko zebrane 
jest w moduł aplikacji (StoreServiceAM) będący odrębną instancją widoków. Jest to przykład prostego mapowania obiektu bazodanowego na BC.
Podczas budowy aplikacji zorientowanej na usługi, należy zaimplementować logikę biznesową jako jeden lub więcej serwisów biznesowych. 
Serwisy te umożliwiają klientom opracowanie zapytań, wstawianie, aktualizację oraz usuwanie rekordów z bazy.
Oracle ADF dostarcza komponenty ułatwiające generowanie serwisów biznesowych opartych na bazie danych co sprawia, że korzystanie z nich
jest bardzo proste. 

\subsection{Mapowanie typów bazy danych}
Ważnym elementem podczas implementacji aplikacji, która zarządza danymi oraz bazą danych jest mapowanie pomiędzy 
istniejącymi typami kolumn a klasami języka JAVA. Większość typów bazy danych posiada swoje odpowiedniki 
zawie\-rające odpowiednie cechy dla danego typu, wyposażone w zestaw odpowiednich metod operujących na konkretnym 
typie danych. Zestawienie zostało zawarte w tabeli \ref{tabela.mapowanie_typow}.

\begin{center}
\begin{longtable}{|C|L|L|}
\caption{Mapowanie pomiędzy typami bazy danych a językiem JAVA. } \label{tabela.mapowanie_typow} \\
\hline \multicolumn{1}{|C|}{\textbf{Typ JAVA}} & \multicolumn{1}{L|}{\textbf{Pakiet}} & \multicolumn{1}{L|}{\textbf{Reprezentacja}} \\ \hline 
\endfirsthead
\multicolumn{3}{c}%
%{{\bfseries \tablename\ \thetable{} -- ciąg dalszy tabeli}} \\
{{ \tablename\ \thetable{} Mapowanie pomiędzy typami bazy danych a językiem JAVA.}} \\

\hline \multicolumn{1}{|C|}{\textbf{Typ JAVA}} & \multicolumn{1}{L|}{\textbf{Pakiet}} & \multicolumn{1}{L|}{\textbf{Reprezentacja}} \\ \hline 
\endhead
%\hline \multicolumn{3}{|r|}{{Ciąg dalszy na następnej stronie}} \\ \hline
\endfoot
\hline \hline
\endlastfoot
Number & oracle.jbo.domain & Dowolny typ numeryczny \\ \hline
Date &  oracle.jbo.domain &  Data  \\ \hline
DBSequence &  oracle.jbo.domain  & Sekwencja, numer otrzymowany przy udziale wyzwalacza\\ \hline
RowID &  oracle.jbo.domain &  Typ ROWID  \\ \hline
Timestamp &  oracle.jbo.domain  & Typ timestamp \\ \hline
TimestampTZ  & oracle.jbo.domain  & Typ timestamp z informacją o strefie \\ \hline
BFileDomain &  oracle.jbo.domain &  Plik binarny (BFILE) \\ \hline
BlobDomain  & oracle.jbo.domain  & Duży obiekt binarny (BLOB) \\ \hline
ClobDomain &  oracle.jbo.domain &  Duży obiekt znakowy (CLOB) \\ \hline
OrdImageDomain  & oracle.ord.im &  Obiekt reprezentujący obraz (ORDIMAGE) \\ \hline
OrdAudioDomain &  oracle.ord.im &  Obiekt reprezentujący obraz audio (ORDAUDIO) \\ \hline
OrdVideoDomain  & oracle.ord.im  & Obiekt reprezentujący obraz wideo (ORDVIDEO) \\ \hline
OrdDocDomain &  oracle.ord.im  & Obiekt reprezentujący obraz dokument (ORDDOC) \\ \hline
Struct &  oracle.jbo.domain  & Struktura zdefiowana przez użytkownika \\ \hline
Array  & oracle.jbo.domain &  Typ kolekcji zdefiniowany przez użytkownika (np. VARRAY) \\ \hline
\end{longtable}
\end{center}

\section{Komponenty}
Opis komponentów biznesowych w ujęciu bardziej praktycznym zamieszczony został w kolejnych podrozdziałach. 
Zaprezentowane jest ujęcie postrzegania komponentów z poziomu ich implementacji w narzędziu programistycznym JDeveloper. 
\subsection{Obiekt encji - Entity Object}
Obiekt encji widoczny na rysunku \ref{fig.entity} zawiera przykładowe mapowania po\-szczególnych kolumn tabeli bazodanowej. W obiekcie encji 
zachowane są typy zdefiniowane z poziomu języka SQL. Umożliwia to podgląd struktury tabeli bez przeglądania zawartości bazy danych, 
co stanowi duży plus i ułatwienie pracy programisty.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.9\textwidth]{picture/entity.png}
\caption{Przykładowy widok encji.} [Źródło: {\em Opracowanie własne.}]
\label{fig.entity}
\end{figure} 

Widać również typ, jaki będą posiadać atrybuty operujące na encji. Typy te związane są z językiem JAVA. 
Na tego rodzaju atrybutach będzie pracował programista. W komponencie encji oprócz odzwierciedlenia kolumn, na jakie 
obiekty języka JAVA będą mapowane, możliwe jest określenie reguł biznesowych. Odzwierciedlają one ograniczenia, 
jakie nakładane są na atrybuty w tabelach. 

Encje są odpowiednim miejscem zdefiniowania odwzorowań tabel posia\-dających relacje z innymi obiektami bazodanowymi.
Każda zdefiniowana relacja udostępnia programiście dostęp do wierszy połączonych z główną encją.
Przy\-kładami relacji są zależności pomiędzy kluczami głównymi oraz obcymi, dające dostęp do tabel powiązanych. 
Każdą synchronizację zmian należy rozpocząć od aktualizacji encji. Następnie należy dbać o reguralną aktualizację po 
każdym wprowadzaniu zmian w schemacie bazodanowym. Brak aktualizacji może przyczynić się do
pojawiania się problemów podczas zatwierdzania zmian do bazy danych.

\subsection{Asocjacje - Associations}
Rysunek \ref{fig.assoc} przedstawia zdefiniowaną asocjację pomiędzy dwoma encjami. Zależność ta bazuje na  zależnościach pomiędzy tabelami.
Stanowi odzwierciedlenie kluczy obcych występujących w bazie danych. Każdą taką relację charakteryzuje krotność relacji.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.9\textwidth]{picture/assoc.png}
\caption{Przykładowy widok asocjacji.} [Źródło: {\em Opracowanie własne.}]
\label{fig.assoc}
\end{figure} 

Z punktu widzenia programisty asocjacje pozwalają na użycie zdefiniowa\-nych relacji w momencie pobierania rekordów podrzędnych. 
Relacje te są niezbędne podczas opracowywania powiązań pomiędzy widokami. W efekcie pozwalają na utworzenie 'drzewa' 
relacji pomiędzy tabelami i wykreowanie z nich instancji modułu, z którego korzysta aplikacja. Ważnym elementem asocjacji 
jest wyznaczenie tabeli źródłowej oraz docelowej. Pozwala to na zdefinio\-wanie akcesorów, czyli metod pobierających lub
ustawiających wartości rekordów powią\-zanych. Ilość uzyskiwanych rekordów oraz ich typ zależy od krotności relacji pomiędzy encjami.

Dobrą praktyką programisty jest zachowywanie prawidłowego odzwiercie\-dlania związków bazodanowych. Jest to ważne, ponieważ na bazie 
asocjacji odwzo\-rowane są relacje zwane linkami. Ich nieaktualny stan może prowadzić do braku spójności zmian wykonywanych pomiędzy 
rekordami zależnymi.

\subsection{Obiekt widoku - View Object}
Obiekt widoku w porównaniu z encjami wygląda bardzo podobnie - posiada zbliżone własności. Jest tak i w rzeczywistości, 
ponieważ większość nich bazuje właśnie na obiektach encji. Obiekty widoku bazujące na encjach są jedynie naj\-prostszym 
przypadkiem zastosowania widoku. Przykład taki znajduje się na rysunku \ref{fig.view}.
Widać na nim, na jakie typy języka JAVA zostały odzwierciedlone typy bazodanowe. 
Jest to istotna informacja dla programisty, gdyż w dalszej części pracy będzie operował na tych typach danych, a nie na typach bazodanowych.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.9\textwidth]{picture/view.png}
\caption{Przykładowy widok komponentu widoku.} [Źródło: {\em Opracowanie własne.}]
\label{fig.view}
\end{figure} 

Komponent biznesowy udostępnia duże możliwości. Daje dostęp do ogro\-mnej liczby usług. 
Można generować atrybuty dynami\-czne oraz chwilowe (ang. {\it{transient}}) przechowujące dane na czas istnienia sesji aplikacyjnej. 
Obiekty te mogą również bazować na zwykłych zapytaniach SQL. Pozwala to na łączenie wielu tabel bazodanowych w jeden widok. 
W takim przypadku staje się on odzwierciedleniem widoku bazodanowego. To jedynie wycinek możliwości, jakie daje 
ADF udostępniając ten przypadek komponentu biznesowego. 
Z punktu widzenia programisty, widoki stanowią bazową informację dla gene\-rowania klasy
JAVA pozwalającej na dostęp do danych z poziomu języka programistycznego. 

\subsection{Linki - View Links}
Analogiczne podobieństwo, jakie istnieje pomiędzy encją a widokiem, widać pomiędzy asocjacją a linkiem. Link jest w większości 
przypadków odzwierciedleniem asocjacji. Jednak podobnie jak widok pozwala na pewną indywidu\-alizację. Rodzaj relacji można zmieniać,
tak jak krotność relacji. Przykład odzwierciedlenia znajduje się na rysunku \ref{fig.link}.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.9\textwidth]{picture/link.png}
\caption{Przykładowy widok linku.} [Źródło: {\em Opracowanie własne.}]
\label{fig.link}
\end{figure} 
\\
Ciekawą właściwością linków jest możliwość definiowana sztucznych relacji po\-między dowolnymi atrybutami równych encji. 
Pozwala to na uzupełnienie brakujących relacji, których nie ma zdefiniowanych w bazie danych a potrzebne są programiście. 
Dzięki temu ingerencja z poziomu SQL nie jest wymagana.

\subsection{Moduł aplikacji - Application Module}
Wszystkie wymienione wyżej komponenty biznesowe stanowią odzwierciedlenie bazy danych rozbudowanej o potrzebne atrybuty oraz 
relacje dla programisty. Brak jednak mechanizmu pozwalającego zebranie oraz zgrupowanie poszczególnych komponentów w całość. 
Oczywiście opis ten świadczy, że istnieje taki komponent jakim. Moduł aplikacji zawiera w sobie 
instancje poszczególnych komponentów biznesowych. Grupowanie jest dowolne a  
modu\-ły można dowolnie zagnieżdżać. Przykład widoczny jest na rysunku \ref{fig.module}.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.9\textwidth]{picture/module.png}
\caption{Przykładowy widok modułu aplikacji.} [Źródło: {\em Opracowanie własne.}]
\label{fig.module}
\end{figure}
\\
Trzeba jednak pamiętać, że opracowując moduł inicjalizowana jest oddzielna instancja danych dla sesji użytkownika. Pojedyncza 
sesja użytkownika, 
w której edytowane są dane, jest odrębną kopią danych. Istnieje możliwość konfliktów pomiędzy poszczególnymi instancjami, 
jednak jest prosty sposób implementacji obsługi takich zdarzeń poprzez wzajemne informowanie czy odświeżanie zmian 
dokonanych przez innych użytkowników. Taki mecha\-nizm trudno spotkać w podstawowym sposobie zarządzania językiem SQL. 

Drugim powodem implementacji komponentu zbiorczego jest udostępnienie programiście enkapsulacji logiki biznesowej w 
jednym miejscu oraz operowania na wielu widokach w jednej metodzie programistycznej. 
Hermetyzacja pozwala na separację tej logiki od warstwy widoku i tym samym od użytkownika. 
\newpage
\subsection{Obsługa zmian modelu}
Na rysunku \ref{fig.schemat_diagram} widać etap synchronizacji zmian w bazie danych. Widoczna jest próba naniesienia zmian na komponent biznesowy. 
Narzędzie JDeveloper w prosty sposób umożliwia taki proces. Podczas odświeżania zmian, JDevelo\-per dba o kaskado\-we uaktualnianie nie tylko
samej encji, ale również wszystkich obiektów ich używających.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.8\textwidth]{picture/synchronize.png}
\caption{Synchronizacja zmian bazodanowych.} [Źródło: {\em Opracowanie własne.}]
\label{fig.schemat_diagram}
\end{figure} 
Pozwala to w prosty sposób utrzymywać aktualny schemat bazodanowy. Minusem takiego podejścia jest obowiązek pamiętania o wykonywaniu 
tego procesu przez programistów. Na szczęście ten proces jest na tyle prosty i automatyczny, że nie powoduje on większych problemów, nawet jeśli 
należy synchronizować większą liczbę zmian.

\chapter{Aplikacja ADF - Baza deweloperów} \label{rozdz.aplikacja}
Celem aplikacji jest pokazanie, jak można w łatwy sposób użyć komponentów biznesowych. Główne zadanie aplikacji to umożliwienie
użytkownikowi programu dostępu do warstwy modelu z poziomu języka JAVA. 

\section{Opis aplikacji}
Implementowana w ramach pracy magisterskiej aplikacja jest przykładem wystawionego interfejsu pozwalającego na dostęp do bazy danych.
Tabele bazodanowe odwzorowane do obiektów widoków zostały zebrane w moduł aplikacji, który stanowi źródło dla stron JSF. 
Poszczególne tabele zebrane są na od\-dzielnych zakładkach. Dostęp do tabel oraz wierszy został zaimplementowany 
w niejednolity sposób, tak aby pokazać wiele różnorodnych możliwości, jakie daje technologia ADF. Część tabel została odzwierciedlona 
w postaci tabel JSF, a część w postaci formatek z przyciskami nawigacji. Cała aplikacja stanowi więc odwzorowanie schematu bazodanowego 
dla formy dostępnej z poziomu przeglądarki umożliwiając przeglądanie i edytowanie danych. 

\section{Narzędzia}
Podczas implementacji aplikacji użyto programu JDeveloper. Jest on wielo\-zadaniowym, kompletnym i zintegrowanym 
środowiskiem projektowym i programowym aplikacji IDE (ang. {\it{Integrated Development Environment}}) 
bazującym na najnowszych rozwiązaniach m.in. dla JAVA, XML i SQL. 
Oracle JDevelo\-per jest przeznaczony do szerokiego grona programistów, nie tylko ze względu na bogaty wybór narzędzi, 
przy jednoczesnym uproszczeniu wielu funkcji, ale również dlatego, że narzędzia dla deweloperów Oracle udostępnia\-ne są za darmo. 

Oracle JDeveloper w porównaniu do podobnych środowisk, jest programem, który zasadniczo zmienia kwestię dostępności narzędzi 
umożliwiających popra\-wę jakości zaimplementowanych aplikacji i ich wydajności. Należy wyróżnić jeden z najszybszych mechanizmów 
służących do debuggowania aplikacji. Dzię\-ki temu nawet programiści z mniejszymi kwalifikacjami i doświadczeniem w programowaniu 
w języku JAVA, mogą szybko odnajdywać rozwiązania problemów z wydajnością kodu poprzez analizę użycia pamięci czy wykonywania 
zapytań w języku SQL. JDeveloper ułatwia programistom implementację nowej generacji aplikacji złożonych z usług biznesowych wielokrotnego użytku. 
Przy projektowaniu Oracle JDeveloper uwzględniono rozszerzenia specyficzne dla języków JAVA, XML, PL/SQL, JSP i HTML, umożliwiając 
programistom pracę w każdym z tych języków. Odpowiada to zapotrzebowaniu większości firm na zwiększenie elastyczności działania. 
JDeveloper jest wizualnym narzędziem, bazującym na komponentach służących do opracowywania, testowania i uruchamia\-nia aplikacji bazodanowych.
Firma Oracle zadbała o to, żeby możliwa była implmentacja rozbudowanych aplikacji trójwarstwowych. Takie rozbudowane narzędzie w znaczący 
sposób ułatwiło implementację aplikacji bazy dewelo\-perów na podstawie modelu danych. \\

Oprócz narzędzia programistycznego JDeveloper użyto SQL Developera pozwalającego na implementację schematu bazodanowego, będącego bazą dla implementowa\-nej 
aplikacji. Narzędzie to świetnie sprawdza się podczas pracy z bazami danych, nie tylko tymi z firmy Oracle. Oprogramowanie
umożliwiło zaprojektowanie oraz zaimplementowanie struktury relacyjnej dla przygotowywanego projektu. Przydatny okazał się również
edytor programisty, wyposażony we wsparcie pisanego kodu, polegającego zarówno na kontekstowej podpowiedzi nazw obiektów, kolumn tabel,
jak i na możliwości automatycznego generowania obiektów języka SQL.\\

Całość została umieszczona na serwerze aplikacyjnym Weblogic, stanowią\-cym szybką, skalowalną technologię umożliwiającą uproszczone
wdrażanie aplikacji i zarządzanie cyklem życia oprogramowania.

\section{Analiza wymagań}

Aplikacja musi stanowić odzwierciedlenie relacji pomiędzy tabelami oraz typów bazodanowych tak, aby było możliwe zarządzanie 
danymi z poziomu zaimple\-mentowanego oprogramowaia. Należy wystawić odpowiedni interfejs dla użyt\-kownika pozwalający na dodawanie, 
usuwanie i edycję istniejących rekordów w bazie. Zebrane podstawowe wymagania to:
\begin{itemize}
 \item Modyfikacja, dodawanie i usuwanie danych.
 \item Przeglądanie danych wraz z możliwością sortowania i filtrowania.
 \item Zapisywanie i cofanie zmian wykonanych w ramach transkacji.
 \item Zarządzanie relacjami oraz kluczami.
\end{itemize}

Przypadki użycia spełniające  wymagania znajdują się na rysunku \ref{fig.usecase001}.
\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth]{picture/usecase001.png}
\caption{Zbiór przypadków użycia.} [Źródło: {\em Opracowanie własne.}]
\label{fig.usecase001}
\end{figure} 

Oprogramowanie umożliwia również wycofanie wykonanych zmian, zapisanie ich fizycznie w bazie danych oraz 
filtrowanie rekordów w tabelach, będących odpowiednikiem kryteriów wyszukiwania w języku SQL.
System ma za zadanie uzupełnie kluczy obcych oraz głównych na podstawie zdefiniowanych relacji, tak aby użytkownik 
podczas dodawania nowych wierszy nie musiał dbać o zachowanie wartości kluczy obcych. Dzięki temu relacje zostaną 
zachowane a użytkownik nie musi przypi\-sywać odpowiednich wartości do kolumn z kluczami. 

\section{Model bazodanowy}
Schemat bazy danych znajduje się na rysunku \ref{fig.schemat.database}. Ze względu na rozmiar, przedstawiona jest jedynie część atrybutów.

Przedstawione są encje wraz z opisem atrybutów znajdujących się w tabe\-lach. 
Klasy JAVA reprezentujące obiekty bazodanowe umieszczone są w pakie\-cie pl.bdv.model.entity.
Na schemacie oprócz tabel i ich nazw znajdują się wartości krotności relacji zachodzące 
pomiędzy obiektami. Przykładowo relacja pomiędzy Developers a Investments to jeden do wielu.
\newpage

\begin{figure}[h!]
    \centering
  \includegraphics[angle=90, height=1.13\textwidth, width=1.1\textwidth]{picture/database.png}
\caption{Schemat relacyjny bazy danych} [Źródło: {\em Opracowanie własne.}]
\label{fig.schemat.database}
\end{figure} 

\newpage

\section{Implementacja projektu}

Implementację projektu należało rozpocząć od utworzenia schematu bazodanowego oraz wykonania odwzorowania tabel oraz 
relacji na postać obiektów encji oraz asocjacji. Zrealizowany pierwszy etap pozwolił na odzwierciedlenie typów 
bazodanowych na obiekty języka JAVA zebrane w postaci obiektów widoków. Widoki natomiast pozwoliły na zamknięcie 
zbioru tych komponentów w moduł aplikacji. Odzwierciedlona struktura znajduje się na rysunku \ref{fig.schemat_dev_application}.
Przygotowane komponenty biznesowe są gotowe do implementacji dalszej części warstwy modelu, kontrolera oraz widoku.

\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth]{picture/instanceAM.png}
\caption{Struktura BC w aplikacji bazy deweloperów.} [Źródło: {\em Opracowanie własne.}]
\label{fig.schemat_dev_application}
\end{figure} 
W dalszej części pracy zostały zaprezentowany opis poszczególnych warstw projektu.

\subsection{Warstwa modelu}
Odwzorowane relacje pomiędzy tabelami, które zostały zebrane w module aplikacji widoczne są na rysunku \ref{fig.schemat_modelDiagram}.

\newpage
\begin{figure}[h!]
    \centering
  \includegraphics[angle=90, height=1.27\textwidth, width=1.1\textwidth]{picture/modelDiagram.png}
\caption{Schemat relacyjny warstwy modelu.} [Źródło: {\em Opracowanie własne.}]
\label{fig.schemat_modelDiagram}
\end{figure} 
\newpage
Model relacji pomiędzy obiektami przedstawiony został w postaci zaprojektowanej instancji modułu aplikacji. 
Struktura ta w dalszej części implementacji stanowić będzie źródło zasilające warstwę kontrole\-ra. Połączenia w postaci 
strzałek opisują kierunki powiązań oraz informują na jaki bazowy obiekt widoku wskazują. Nazwy znajdujące się w prostokątach 
to przykła\-dowa instancja zaimplementowana do wystawienia interfejsu dla dostępu do danych.

\subsection{Warstwa kontrolera}
Warstwa kontrolera stanowi metody, atrybuty oraz struktury służące bezpośrednio do odczytywania danych z komponentów biznesowych. 
Przykład definicji strony dającej dostęp do tych zasobów znajduje się na rysunku \ref{fig.controller}. 
\begin{figure}[h!]
    \centering
  \includegraphics[height=0.5\textwidth, width=1.0\textwidth]{picture/controller.png}
\caption{Przykład definicji strony będącej kontrolerem aplikacji.} [Źródło: {\em Opracowanie własne.}]
\label{fig.controller}
\end{figure} 
Każda definicja podzielona jest na trzy sekcje. Pierwsza z nich {\it{Bindings}} to atrybuty oraz metody 
bezpośrednio używane przez warstwę widoku. Kolejna sekcja {\it{Executables}}
czerpie dane z struktur odczytujących dane z komponentów biznesowych. Przykładowo może zawierać iteratory do przeglądania danych lub metod. 
Ostatnia sekcja to {\it{Data Control}} służąca do wskazywania odpowiednich komponentów biznesowych przez poprzednią sekcję. 

\subsection{Warstwa widoku}
Przykładowy ekran z zaimplementowanej aplikacji przedstawiony jest na rysunku \ref{fig.application}. Całość aplikacji to pogrupowane na zakładki 
obiekty widoku. Większość od\-zwierciedlona jest w postaci formatek do śledzenia konkretnych wierszy 
lub całych tabel. Intuicyjny i prosty interfejs graficzny służy do wykonywania operacji na danych oraz ich przeglądania. 
\begin{figure}[h!]
    \centering
  \includegraphics[height=1.00\textwidth, width=1.0\textwidth]{picture/application.png}
\caption{Przykładowy zrzut ekranu z aplikacji do edytowania danych.} [Źródło: {\em Opracowanie własne.}]
\label{fig.application}
\end{figure} 

Innym przykładem funkcji zrealizowanej w aplikacji jest możliwość filtrowania oraz sortowania wpisów po dowolnym atrybucie. 
Przykład takiego rozwiązania znajduje się na rysunku \ref{fig.application2}. Zrealizowane jest to poprzez udostępnienie użytkownikowi 
dodatkowego wiersza w tabeli, w którym możliwe jest wpisywanie atrybutów. Po uzupełnionych wartościach zostanie dokonane dynamiczne filtrowanie wierszy. 
\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth]{picture/application2.png}
\caption{Przykładowy zrzut ekranu z aplikacji do filtrowania danych.} [Źródło: {\em Opracowanie własne.}]
\label{fig.application2}
\end{figure} 

\subsection{Podsumowanie implementacji oraz opis realizacji projektu}
    
Wykonanie odwzorowania pomiędzy obiektami bazodanowymi a komponentami biznesowymi pozwoliło w łatwy sposób zbudować 
poszczególne warstwy w aplikacji. Prawidłowe zaprojektowanie warstwy modelu oraz bazującego na niej kontrolera 
umożliwiło proste wystawienie interfejsu użytkownika. Kolej\-ne warstwy zostały zaimplementowane zgodnie zasadami z przedstawionymi 
w roz\-dziale \ref{label.patterns}. 

Implementacja wzorców projektowych pozwala na określenie aplikacji 
jako przejrzystej. Oprogramowanie takie charakteryzuje się wysoką jakością kodu. Wszystkie klasy JAVA, zarówno obiekty mapujące wiersze oraz 
poszczególne tabele zostały zaimplementowane zgodnie z standardami frameworka ADF oraz podstawowych zasad 
programistycznych. Zebrane w całość warstwy stano\-wią aplikację bazy deweloperów reali\-zującą dostęp do danych z 
poziomu aplikacji uruchamianej w oknie przeglądarki bez instalacji oprogramowania.

Znaczna część została zostawiona w postaci wygenerowanej tak, aby zaprezentować w jak sprawny i szybki możliwe 
jest wygenerowanie odpowiedniego interfejsu dla edycji danych, dostępnego z aplikacji webowej. Tak zaimplementowane 
oprogramowanie w pełni realizuje założone wymagania oraz pozwala na dokonanie porównania pomiędzy standardową 
realizacją edycji danych z poziomu języka SQL oraz na wykonanie analizy porównawczej. Umożliwi 
opisanie wniosków wynikających z poszczególnych rozwiązań oraz realizację podsumowania dla poszczególnych sposobów. 

\chapter{Testowanie oraz porównanie SQL i BC}

Kolejny rozdział przedstawia tok realizacji testów aplikacji oraz poszczególnych rozwiązań. Przeprowadzone 
i opisane zostały zarówno ogólne testy samej aplikacji oraz te skupiające się na na najważniejszych elementach 
pracy czyli na wydajności oraz poprawnym działaniu komponentów biznesowych. Zagadnienia teoretyczne, implementacja 
oraz testy pozwoliły na dokonanie dogłębnej analizy BC, wskazania różnic pomiędzy językiem SQL 
oraz ogólnego podejścia do edycji danych. Koniec rozdziału to wskazanie poszczególnych zalet i wad dla obu rozwiązań 
jakie wynikają z sposobu użyt\-kowa\-nia technologii. 

\section{Testowanie BC}
Proces testowania rozpoczęto od sprawdzenia powiązań pomiędzy poszczególnymi komponentami biznesowymi. 
Odbyło się to przy udziale wybudowanego w narzędzie JDeveloper testera. Przykładowy ekran widoczny jest na rysunku \ref{fig.bctester}. 
Pozwala on na wprowadzanie oraz edycję danych znajdujących się w bazie danych. Używając go, można w prosty sposób sprawdzić 
zależności pomiędzy poszczególnymi tabelami oraz kluczami. Tester ten jest bardzo przydany dla programistów. Możliwe jest 
operowanie na modelu na podstawie domyślnie wygenerowanego interfejsu. Dzięki niemu programista nie musi generować sam interfejsu 
oraz warstwy kontrolera, aby móc testować warstwę modelu.

Tester ten jest dobrym sposobem na sprawdzenie oraz pierwsze próby zarządzania modelem przy użyciu wygenerowanej 
instancji modułu aplikacji.

\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth]{picture/bctester.png}
\caption{Przykładowy ekran z wbudowanego testera BC.} [Źródło: {\em Opracowanie własne.}]
\label{fig.bctester}
\end{figure}

\section{Testowanie aplikacji}
Testy aplikacji pozwalają na wnikliwe zbadanie całej aplikacji pod kątem zarów\-no poszczególnych funkcji systemu, interfejsu 
użytkownika czy wydajności dostępu do komponentów biznesowych i danych z poziomu aplikacji. Poszcze\-gólne etapy przeprowadzonych 
testów pozwolą na określenie jakie są możliwości aplikacji oraz jej wydajność. Wyniki testów umożliwią dokonanie porównania 
z dostępem do danych z poziomu języka SQL oraz pozwoli na wskazanie zarówno zalet jak i wad poszczególnych rozwiązań.

\subsection{Testy jednostkowe}
Testy jednostkowe systemu dają możliwość przetestowania poszczególnych me\-tod zaimplementowanych przez programistę oraz 
umożliwiają granularne spraw\-dzenie poszczególnych, jednostkowych funkcji. 

Na potrzeby pracy magisterskiej w aplikacji 
zostaną przetestowane dostępy do poszczególnych komponentów biznesowych oraz do znajdujących się w nich danych. 
Dzięki temu istnieje możliwość sprawdzenia metod języka JAVA pozwalających na wykonywanie operacji na zbiorach danych 
lub poszczególnych atrybutach. 

\subsubsection{Przygotowanie testów}
Testy jednostkowe przygotowane zostały na podstawie szablonu testów funkcji komponentów biznesowych udostępnianych 
przez narzędzie JDeveloper. Wzór ten generuje szkielet testów jednostkowych na podstawie wskazanego komponentu, 
w przypadku opracowywanej aplikacji szablon został użyty dla dwóch instancji modułów aplikacji wraz z wszystkimi obiektami 
widoku. Przykład zaimplementowanych testów w języku JAVA znajduje się na rysunku \ref{fig.junitsList}.
\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth, height=0.33\textheight]{picture/junitsList.png}
\caption{Zaimplementowanie testów dostępu.} [Źródło: {\em Opracowanie własne.}]
\label{fig.junitsList}
\end{figure}

Widać na nich pogrupowane klasy JAVA posiadające strukturę testu spraw\-dzającego utworzenie instancji modułu aplikacji 
oraz na uzyskanie dostępu do poszczególnych obiektów widoku.
\newpage
\subsubsection{Przeprowadzenie testów}
Implementacje kolejnych testów jednostkowych dla pojedynczych komponentów biznesowych zebrane razem tworzą zbiór pozwalający 
na przetestowanie dostępu dla całej instancji modułu aplikacji. Po wykonaniu wszystkich pojedynczych testów zostały one połączone
w jedną grupę, a następnie wykonane. Rezultat widoczny jest na rysunku \ref{fig.junitResult}.
\begin{figure}[h!]
    \centering
  \includegraphics[width=1.0\textwidth, height=0.5\textheight]{picture/junitResult.png}
\caption{Przeprowadzenie testów dostępów do obiektów widoku.} [Źródło: {\em Opracowanie własne.}]
\label{fig.junitResult}
\end{figure}

\subsubsection{Wyniki}
Wynikiem zaimplementowanych i uruchomionych testów jednostkowych jest przetestowanie komponentów biznesowych oraz ich dostęp 
do bazy danych. Dzięki nim zostaje dostarczona informacja, czy podstawowe funkcje działają. Możliwe jest sprawdzenie 
odzwierciedlenia i mapowania pomiędzy tabelami a obiektami w aplikacji. Przeprowadzone testy powinny być rozwijane 
z każdym przyrostem funkcji oraz dodatkowych usług. 
\newpage
\subsection{Testy niefunkcjonale}

Testy niefunkcjonalne sprawdzają cechy jakościowe części lub całości systemu. Podczas ich przeprowadzania brane są pod uwagę 
aspekty oprogramowania, które nie są związane z określoną funkcją lub działaniem użytkownika. Należą do nich skalowalność, czas 
odpowiedzi aplikacji i bezpieczeństwo. Dla potrzeb pracy magisterskiej zostało zrealizowane monitorowanie obciążenia 
aplikacji. Zaimplementowana aplikacja do operowania na modelu charakteryzuje się war\-tościami parametrów różniącymi się od tych
występujących przy zastosowania języka SQL. Ważnym aspektem pracy jest sprawdzenie wydajności aplikacji, 
a tym samym możliwości użycia komponentów biznesowych. 
\subsubsection{Przygotowanie środowiska}
Zastosowanym narzędziem do monitorowania parametrów aplikacji jest Oracle Enterprise Manager. 
Pozwala on na kontrolę użycia zasobów, liczbę aktywnych sesji oraz liczbę klas JAVA wraz z ilością odwołań do beanów. 
\begin{figure}[h!]
    \centering
  \includegraphics[angle=0, width=0.9\textwidth]{picture/em01.png}
\caption{Dostępne parametry do nadzorowania aplikacji ADF.} [Źródło: {\em Opracowanie własne.}]
\label{fig.em1}
\end{figure} 
\subsubsection{Monitorowanie}
Podczas monitorowania aplikacji analizowana była liczba żądań występujących podczas jednej sesji użytkownika 
podczas wykonywania testów Selenium. Udało wygenerować się liczbę 400 żądań na minutę. 
Przy takim obciążeniu responsywność aplikacji nie uległa pogorszeniu. 
Świadczą o tym czasy realizacji żądań które nie przekraczają 125 ms. 
\begin{figure}[h!]
    \centering
  \includegraphics[angle=90, height=0.9\textwidth, width=0.9\textwidth]{picture/em02.png}
\caption{Nadzorowanie parametrów aplikacji.} [Źródło: {\em Opracowanie własne.}]
\label{fig.em2}
\end{figure} 

\subsubsection{Wyniki}
Przeprowadzony test generowania dużej ilości żądań wykazał, że aplikacja mimo znacznej liczby realizowanych 
ope\-racji jest w stanie obsłużyć je w krótkim odstępie czasu. Pozwala to stwierdzić, że standardowy czas wykonywania 
operacji SQL nie jest w dużej mierze wydłużony przez zastosowanie aplikacji webowej w technologii ADF oraz wzrost
czasów obsługi danych nie jest znaczący. 
\newpage

\subsection{Testy funkcjonalne}
Zadaniem testów funkcjonalnych jest sprawdzenie oprogramowania pod kątem wymagań stawianych systemowi oraz sprawdzenie 
czy aplikacja zachowuje się w oczekiwany sposób. Testy funkcjonalne pokrywają zarówno funkcje dostępne dla użytkownika 
poprzez interfejs aplikacji jak i operacje wykonywane przez system, które nie są widoczne dla zwykłego użytkownika. 
Realizowane są zwykle na koniec cyklu wytwarzania oprogramowania, jednak o ile możliwe jest przetestowanie części 
funkcjonalności, powinny być wykonane jak najwcześniej.  W pracy magisterskiej testy te sprawdzają realizację wymagań 
systemu oraz sprawdzają interfejs użytkownika.

\subsubsection{Przygotowanie testów}
Przygotowane i implementacja testów funkcjonalnych zostało zrealizowane przy pomocy przeglądarki Firefox oraz środowiska Selenium.
\begin{figure}[h!]
    \centering
  \includegraphics[width=0.8\textwidth, height=0.50\textheight]{picture/selenium1.png}
\caption{Implementacja pojedynczego testu.} [Źródło: {\em Opracowanie własne.}]
\label{fig.selenium1}
\end{figure}
\newpage
Na rysunku \ref{fig.selenium1} widać kolejne akcje wykonywane przez użytkownika opisane za pomocą komend Selenium. 
Zbiór akcji realizowanych przez użytkownika został odwzorowany za pomocą skryptu. Pozwala on na symulacje 
korzystającego z aplikacji użytkownika i tym samym w znacznie szybszym stopniu na sprawdzenie zaimplementowanych 
funkcji. Testy takie zdecydowanie dłużej są pisane niż jednorazowe testowania przez użytkownika, ale 
w dalszej perspektywie umożliwiają na automatyzację procesu weryfikacji funkcjonalności systemu.

\subsubsection{Przeprowadzenie testów}
Zbiór pojedynczych testów Selenium został zebrany w jedną grupę, pozwalającą na sprawdzenie całego zbioru wymagań funkcjonalnych 
realizowanych przez aplikację. Rezultat przeprowadzonych testów znajduje się na rysunku \ref{fig.selenium2}. 

\begin{figure}[h!]
    \centering
  \includegraphics[width=0.8\textwidth, height=0.50\textheight]{picture/selenium2.png}
\caption{Resultat wykonania kilku testów Selenium.} [Źródło: {\em Opracowanie własne.}]
\label{fig.selenium2}
\end{figure}
Widać na nim efekt wykonania całego zbioru testów funkcjonalnych spraw\-dzających interfejs użytkownika. Sprawdzone zostaje 
posługiwanie się aplikacją poprzez dodawanie, usuwanie i edycję danych z poziomu aplikacji wraz z zapisem danych do bazy.
Poszczególne testy znajdują się w sekcji {\it{Test Case}}. Główna część przykładowego ekranu zawiera komendy skryptu Selenium operujące 
na elementach strony tj. przyciski, pola tekstowe. Wynik uruchomionych testów znajduje się pod sekcją z nazwami testów z informacją o liczbie 
testów (5) oraz o ilości nieudanych prób (0). Wynika z tego, że wszystkie próby zakończyły się sukcesem.
\subsubsection{Wyniki}
Przeprowadzone testy funkcjonalne pozwalają na przyśpieszenie procesu testo\-wania interfejsu użytkownika oraz sprawdzenie 
funkcji z poziomu o\-soby użytkującej aplikację. Rezultatem testów Selenium jest automatyczna weryfikacja przedstawionych 
założeń. Stanowią one potwierdzenie, że w aplikacji zostały zaimplementowane założone funkcje wraz z odpowiednim ich sprawdzeniem. 
\section{Zalety i wady rozwiązań}
Wyjaśnienia teoretyczne, zaimplementowana aplikacja oraz wszystkie przepro\-wadzone testy pozwalają określić występujące 
zalety oraz wady dla poszczególnych technologii dostępu do danych oraz ich modyfikację. Poniżej znajduje się wykaz plusów 
i minusów dla języka SQL oraz komponentów biznesowych w różnych aspektach użycia. 
\begin{center}
\begin{longtable}{|M|M|}
\caption{Zalety oraz wady SQL podczas zarządzania warstwą modelu. } \label{tabela.plusminus.sql} \\

\hline \multicolumn{1}{|M|}{\textbf{Zalety}} & \multicolumn{1}{M|}{\textbf{Wady}} \\ \hline 

\endfirsthead

\multicolumn{2}{c}%
%{{\bfseries \tablename\ \thetable{} -- ciąg dalszy tabeli}} \\
{{ \tablename\ \thetable{} Zalety oraz wady SQL podczas zarządzania warstwą modelu.}} \\

\hline \multicolumn{1}{|M|}{\textbf{Zalety}} & \multicolumn{1}{M|}{\textbf{Wady}}  \\ \hline 
\endhead

%\hline \multicolumn{2}{|r|}{{Ciąg dalszy na następnej stronie}} \\ \hline
\endfoot

\hline \hline
\endlastfoot
definiowanie procedur, funkcji czyli możliwość implementacji powtarzalnych bloków instrukcji realizujących wymagania funkcjonalne
& ściśle określony interfejs zależny od aplikacji \\ \hline
 
efektywne mechanizmy realizacji zapytań poprzez bezpośrednie operowanie na tabelach 
&  brak prostych mechanizmów do opracowania zapytań rekurencyjnych \\ \hline

nie trzeba interfejsu do obsługi danych
&  brak prostego mechanizmu uaktualniania wartości kluczy obcych przy zmianie wartości klucza głównego \\ \hline

wiele narzędzi do obsługi uniwersalnego języka SQL
& ograniczony dostęp do zbioru metod dostępnych w technologii \\ \hline

gotowe narzędzia zapewniają stabilność pracy i większą bezbłędność
&  \\ \hline

brak potrzeby synchronizacji zmian z oddzielną aplikacją do zarządzania danymi
&  \\ \hline

duże wsparcie narzędzi do generowania gotowego kodu SQL
&  \\ \hline

\end{longtable}
\end{center}


\begin{center}
\begin{longtable}{|M|M|}
\caption{Zalety oraz wady BC podczas zarządzania warstwą modelu. } \label{tabela.plusminus.bc} \\

\hline \multicolumn{1}{|M|}{\textbf{Zalety}} & \multicolumn{1}{M|}{\textbf{Wady}} \\ \hline 

\endfirsthead

\multicolumn{2}{c}%
%{{\bfseries \tablename\ \thetable{} -- ciąg dalszy tabeli}} \\
{{ \tablename\ \thetable{} Zalety oraz wady BC podczas zarządzania warstwą modelu.}} \\

\hline \multicolumn{1}{|M|}{\textbf{Zalety}} & \multicolumn{1}{M|}{\textbf{Wady}}  \\ \hline 
\endhead

%\hline \multicolumn{2}{|r|}{{Ciąg dalszy na następnej stronie}} \\ \hline
\endfoot

\hline \hline
\endlastfoot
proste mechanizmy dziedziczenie i enkapsulacji znanych z języka JAVA 
& mała uniwersalność dla różnego rodzaju schematów, implementacja interfejsu do zarządzania określoną strukturą wymaga generowania komponentów biznesowych dla każdego nowej tabeli \\ \hline

budowanie własnego interfejsu umożliwia dopasowanie formatek oraz wyglądu aplikacji do preferencji użytkowników, który może być w prosty sposób zmieniany 
& brak automatycznej kontroli nad zmianą schematu, wymaga na programiście cyklicznej kontroli nad zmieniającym się schematem bazodanowym \\ \hline

ADF udostępnia dużą liczbę gotowych komponentów, formatek generowanych na podstawie komponentów biznesowych 
& wygenerowane odzwierciedlenie struktury bazodanowej wymaga przeprowadzenia testów działającego systemu \\ \hline

ADF bazując na języku JAVA pozwala na definiowanie złożonych typów i obiektów 
& możliwość popełnienia błędów podczas generowania komponentów biznesowych, mogą generować problemy podczas modyfikacji danych \\ \hline

definiowanie funkcji realizujących wymagania biznesowe przypisanych do całego zbioru komponentów jak i do pojedynczych danych
&  wymaga zatrudnienia specjalisty od technologii ADF \\ \hline

prosty system wywołań rekurencyjnych 
& ścisłe powiązanie i zależność działania od bazy danych, bez którego uruchomienie aplikacji nie jest możliwe \\ \hline

wprowadzanie dodatkowych ograniczeń i walidacji z poziomu języka JAVA lub interfejsu pozwala na wprowadzanie nowych restrykcji danych, 
oraz wymuszaniu na użytkowniku wprowadzania określonych wartości, np. określony zakres liczb czy znaków 
& wymaga utrzymania serwera, na którym znajduje się aplikacja \\ \hline

konwersja wyświetlanych danych do dowolnego formatu pozwala na reprezentację danych w bardziej przejrzystym wyglądzie i formacie 
& brak możliwości dokonania zmiany struktury obiektów bazodanowych, możliwe jedynie wywoływanie poleceń języka SQL z poziomu kodu języka JAVA
\\ \hline

prosta internacjonalizacja interfejsu, pozwala na używanie tej samej aplikacji w różnych językach przez różne osoby 
&  \\ \hline

możliwość opracowania i wywoływania zapytań z poziomu języka JAVA, pozwalająca na wykonywanie dowolnego zapytania z języka SQL
&  \\ \hline

\end{longtable}
\end{center}

\section{Porównanie SQL i BC}
Zaimplementowana aplikacja do zarządzania warstwą modelu przy użyciu fra\-meworka ADF oraz wskazanie zalet 
i wad poszczególnych rozwiązań pozwala na dokonanie porównania pomiędzy technologiami. Zebrane cechy wraz 
ze wskazaniem różnic pomiędzy nimi oraz określenie elementów wspólnych znaj\-duje się w tabeli \ref{tabela.plusminus.bc}. 
Zestawienie cech pozwala na określenie, jakie korzyści pojawia\-ją się przy użyciu poszczególnych rozwiązań 
oraz w jakich aspektach dana technologia jest lepsza czy gorsza.

\begin{center}
\begin{longtable}{|C|L|L|}
\caption{Porównanie SQL i BC. } \label{tabela.plusminus.bcsql} \\

\hline \multicolumn{1}{|C|}{\textbf{}} & \multicolumn{1}{L|}{\textbf{BC}} 
& \multicolumn{1}{L|}{\textbf{SQL}} \\ \hline 

\endfirsthead

\multicolumn{3}{c}%
%{{\bfseries \tablename\ \thetable{} -- ciąg dalszy tabeli}} \\
{{ \tablename\ \thetable{} Porównanie SQL i BC.}} \\

\hline \multicolumn{1}{|C|}{\textbf{}} & \multicolumn{1}{L|}{\textbf{BC}} 
& \multicolumn{1}{L|}{\textbf{SQL}} \\ \hline 
\endhead

%\hline \multicolumn{3}{|r|}{{Ciąg dalszy na następnej stronie}} \\ \hline
\endfoot

\hline \hline
\endlastfoot
\textbf{koszt obsługi}
& Znacznie większy koszt niż w przypadku samego języka SQL. Do utrzymania potrzebny jest serwer, na którym zostanie zainstalowana aplikacja. 
Potrzebny jest również specjalista od technologii ADF. 
& Mniejsze koszty niż w przypadku ADF. Utrzymanie serwera bazy danych. \\ \hline

\textbf{wydajność}
& W przypadku aplikacji ADF do czasu wykonywania zapytania dochodzi czas obsługi żądań generowanych przez użytkownika 
a obsługiwanych przez serwer, który w przypadku jednej sesji użytkownika jest czasem mało znaczącym 
i nie wpływającym na wydajność aplikacji.  
& Wydajność obsługi modelu danych zależy jedynie od czasu wykonywania zapytań SQL. Na czas ten ma wpływ złożoność kwerendy. \\ \hline

\textbf{elastyczność i możliwość zmian schematu}
& Brak możliwości wykonywania skryptów SQL z poziomu aplikacji. Wymaga synchronizacji przy zmianach schematu.
& Bezpośrednie operowanie na schemacie, możliwość wykonywania zapytań oraz edycja schematu z poziomu edytorów. \\ \hline

\textbf{wygoda obsługi}
& Możliwość dostosowywania wyglądu aplikacji do preferencji użytkowników oraz jego dowolne modelowanie.
& Dostęp i wygoda do schematu poprzez wiele sprawdzonych i wydajnych narzędzi. Zapewniają one wysoki poziom usług. \\ \hline

\textbf{personalizacja}
& Możliwość dostosowywania interfejsu do indywidualnych potrzeb. Ogromna liczba gotowych kontrolek do implementacji 
zapewniają duże możliwości dla programisty. 
& Duży wybór narzędzi, jednak brak większych możliwości na dowolną zmianę interfejsu użytkownika. \\ \hline

\textbf{dostęp do danych}
& Dostęp do danych oraz schematu odbywa się poprzez wewnętrzne struktury technologii ADF.
& Bezpośredni dostęp do danych oraz do schematu bazodanowego. \\ \hline

\textbf{wymagana wiedza}
& Oprócz języka zapytań wymagana znajomość technologii ADF do implementacji interfejsu oraz komponentów BC.
& Znajomość języka SQL bardzo przydatna, ale przy użyciu edytorów nie jest wymagana. \\ \hline

\textbf{możliwości testowania}
& Szeroki zestaw możliwości testowania poszczególnych funkcji, struktur oraz danych.
& Brak możliwości testowania. \\ \hline

\end{longtable}
\end{center}

\section{Zastosowanie porównywanych technologii}
Tabela \ref{tabela.plusminus.bcsql} zawiera porównanie dla poszczególnych technologii. Zarówno język SQL oraz komponenty 
biznesowe posiadają swoje zalety oraz wady. Język zapytań to standardowy sposób na dostęp do danych z poziomu linii komend 
oraz opracowanych narzędzi graficznych umożliwiających przeglądanie struktury bazodanowej bez znajomości samego języka. 
BC dają natomiast możliwość skonstruowania aplikacji, do której jest możliwość uzyskać dostęp bez specja\-listycznych narzędzi. 
Wystarczy przeglądarka internetowa. W tym przypadku potrzeba jednak dodatkowych środków na uruchomienie serwera oraz wykupie\-nie 
licencji ADF do rozwiązań biznesowych. Dobrze zaimplementowany interfejs oraz odpowiednio użyte 
kontroleki graficzne sprawiają, że edycja da\-nych jest dużo bardziej uproszczona. Każda zmiana interfejsu możliwa 
jest przez programistę. BC dają również możliwość na implementację i wywoływanie skomplikowanej logiki biznesowej 
oddzielonej bezpośrednio od użytkowni\-ka. Wynika z tego, że jeżeli zaistnieje potrzeba udostępnić użytkownikowi możliwość 
wykonywania operacji oddzielając jednocześnie sposób jego wykonania od samego rezultatu zdecydowanie lepiej jest zastosować aplikację 
ADF i użyć komponentów biznesowych. Dla mniej skomplikowanej logiki i prostych opera\-cji zmiany danych 
lepiej używać języka SQL. 

\section{Dalszy rozwój technologii ADF}
ADF to technologia charakteryzująca się wysoką złożonością oraz rozbudowaną strukturą, która ciągle jest
rozwijana. Kolejne wersje poprawiają jakość dostarczanych narzędzi oraz mechanizmów implementacji i uruchamiania
aplikacji. Tworzenie aplikacji webowych i desktopowych zostało rozszerzone o aplikacje mobilne,
co sprawia, że technologia nie jest tylko rozwijana na komputery, ale przeznaczona jest dla dużo większego
grona odbiorców. Użyte komponenty biznesowe stanowią mały wycinek możliwości udostępnianych przez
framework, a mimo to ich rozbudowane mechanizmy obsługi i zarządzania danymi dostarczają ogromną liczbę
możliwości. Każda nowa wersja poprawia ich działanie oraz dostarczanie nowych możliwości. Rozbudowie zwykle towarzyszy porawa wydajności.
Nie ma wątpliwości, że przy tak zaawansowanej technologii dalszy rozwój ADF i zwiększenie popularności jest
nieuniknione. Prostota, jakość wykonania oraz dostępne rozwiązania gwarantują sukces frameworka, a 
implementacja aplikacji przy jego użyciu w znacznym stopniu skraca czas spędzony przy opracowywaniu aplikacji.

\chapter{Podsumowanie} \label{rozdz.podsumowanie}

\section{Podsumowanie i wnioski}

W pracy zaprezentowany został sposób zarządzania mode\-lem przy pomocy komponentów biznesowych. 
Przedstawione zastosowania technologii ADF w znaczący sposób przyczynią się do przekonania do nowych 
rozwiązań uzyskania dostępu do danych oraz implementacji wygodnego interfejsu do wykonywania operacji na modelu. 
Zaimplementowane oprogramo\-wanie jest doskonałym, praktycznym przykładem na użycie technologii ADF.  
Szybki rozwój technologii internetowych sprawia, że są wprowadzane zmiany i rozszerzana funkcjonalność całego 
środowiska tak, aby sprostać nawet najbardziej wymagającym użytkownikom. JDeveloper jest niespełna dziesięcioletnim 
środowiskiem, które jest stale rozwijane przez programistów firmy Oracle. Zastosowanie komponentów biznesowych 
w dużym stopniu umożliwiło twórcom oprogramowania dostęp do modelu danych w bardzo wy\-godny i przyjazny dla nich sposób. 
Cały mechanizm zarządzania oraz logika operująca na rekordach bazy danych została przeniesiona do aplikacji 
implementowanej przez programistów w języku JAVA. 

W poszczególnych rozdziałach szczegółowo został przedstawiony framework ADF oraz komponenty biznesowe na tle języka SQL. 
Zaprezentowane zostały technologie stosowane i zaimplementowane w postaci aplikacji webowych. Wstęp do samej technologii
poprzez omówienie poszcze\-gólnych ele\-mentów umożliwił czytelnikowi poznanie szerokiej oferty 
programistycznej i funkcjonalnej, jaką udostępnia ADF. Zrealizowane porównanie pomiędzy technologią SQL i ADF pozwoliło na wskazanie
ich mocnych i słabych stron. Zaprezentowane zalety i wady dają możliwość określenia w jakiej sytuacji zastosować
dane rozwiązanie. 

Użycie konkretnych rozwiązań technicznych uwarunkowane jest docelowym przeznaczeniem oraz typem docelowego odbiorcy. Użytkownik decyduje 
o sposobie do\-stępu poprzez gotowe narzędzia lub zaimplementowane przez programistów oprogramowanie. Na decyzję mają również
wpływ warunki finansowe, jakimi dysponuje klient lub odbiorca oprogramowania. Większe koszty poniesione wraz z zastosowaniem 
frameworka ADF zwracają się poprzez dowolne dostosowanie wyglądu oprogramowania wraz z realizacją wymagań biznesowych, 
zaimplementowanych w komponentach biznesowych.

\section{Perspektywy dalszych badań}
Technologia ADF jako mało popularna, a jednocześnie perspektywiczna, umo\-żliwia dalszy rozwój oraz prowadzenie dalszych analiz 
i badań związanych z framoworkiem. Wiele elementów daje możliwość zestawienia porównania z instniejącymi, 
bardziej popularnymi rozwiązaniami nie tylko w dziedzinie dostępu do danych. 
W pracy większa ilości testów wydaj\-nościowych pozwoliłaby na zrealizowanie lepszej analizy porównawczej 
w aspekcie efektywności oprogramowania oraz rozbudowę zagadnień związanych z efektywnością nowego rozwiązania. 

\addcontentsline{toc}{chapter}{Bibliografia}
\begin{thebibliography}{99}

\bibitem{bib_adf_start_guide} Ronald G., Quick Start Guide to Oracle Fusion Development, Mcgraw-Hill Publ. Comp. 2010
\bibitem{bib_adf_cookbook} Haralabidis N., Oracle JDeveloper 11gR2 Cookbook, PACKT PUB 2012
\bibitem{bib_adf_guide} Nimphius F., Munsinger L., Oracle Fusion Developer Guide, Mcgraw-Hill Publ.Comp. 2010
\bibitem{bib_adf_handbook} Mills D., Koletzke P., Roy-Faderman A., Oracle JDeveloper 11g Handbook, Mcgraw-Hill Publ. Comp. 2009
\bibitem{bib_doc_adf} http://www.oracle.com/technetwork/developer-tools/jdev/documentat (stan na 03.11.2012r.)
\bibitem{bib_doc_sqldeveloper} http://docs.oracle.com/cd/E35137\_01/index.htm (stan na 03.11.2012r.)
\bibitem{bib_doc_database} http://www.oracle.com/pls/db112/homepage (stan na 03.11.2012r.)
\bibitem{bib_adf_architecture} http://imdjkoch.files.wordpress.com/2012/04/adf-architecture.jpg (stan na 03.11.2012r.)
\bibitem{bib_diagram_bc} 
http://4.bp.blogspot.com/\_Y8eLenGvPHg/TQ0LAEGcOXI/AAAAA
AAAAaA/c3qa4gfRq70/s1600/beginning\_of\_eovo.gif (stan na 03.11.2012r.)
\bibitem{bib_beans} http://4.bp.blogspot.com/\_-zCppT60vlk/TOE4v93g23I/AAAAAAAAEQg/
gbs\_Yv3Ttsc/s1600/adf\_scopes.JPG (stan na 10.12.2012r.)
\bibitem{bib_beans_pic} http://one-size-doesnt-fit-all.blogspot.com/2011/11/adf-faces-logic-bomb-in-order-of-bean.html (stan na 14.12.2012r.)
\bibitem{bib_adf_xml} Vohra D., Processing XML documents with Oracle JDeveloper 11g, PACKT PUB 2009
\bibitem{bib_adf_adftraining} http://adftraining.com/ (stan na 14.06.2013r.)
\bibitem{bib_adf_ajax} Vohra D., Ajax in Oracle JDeveloper, Springer-Verlag GmbH 2008
\bibitem{bib_adf_learnoracleadf} http://www.learnoracleadf.com/ (stan na 14.06.2013r.)
\bibitem{bib_adf_ecourse1} http://download.oracle.com/tutorials/jtcd3/ecourse\_adf\_part1/html/
temp\_frameset/index.htm (stan na 14.02.2013r.)
\bibitem{bib_adf_ecourse2} http://download.oracle.com/tutorials/jtcd3/ecourse\_adf\_part2/html/
temp\_frameset/index.htm (stan na 14.02.2013r.)
\bibitem{bib_adf_real_world} Purushothaman J., Oracle ADF Real World Developer's Guide, PACKT PUB 2008
\bibitem{bib_adf_adftutorials} http://www.adftutorials.com/ (stan na 14.06.2013r.)
\bibitem{bib_adf_maishareef_adftutorials} http://maishareef.com/adftutorials.php (stan na 14.06.2013r.)
\bibitem{bib_oracle_database} Greenwald R., Stackowiak R., Stern J., Oracle Essentials, 4th Edition, O'Reilly Media 2007
\bibitem{bib_adf_jdbc} Vohra D., JDBC 4.0 and Oracle JDeveloper for J2EE Development, PACKT PUB 2012
\bibitem{bib_adf_made_sample} Vesterli E., Oracle ADF Enterprise Application Development—Made Simple, PACKT PUB 2011


\end{thebibliography}

\addcontentsline{toc}{chapter}{Abstract)} 
\chapter*{Abstract}
{\LARGE {Management of model layer using Business \newline Components in Oracle Application Development Framework}}
\newline
\newline
\newline
This thesis describes model layer management with Business Components in Oracle Application Development technology.
ADF is an end-to-end
application framework that builds on Java Platform, Enterprise Edition (Java EE)
standards and open-source technologies. Framework which simplifies Java EE development by minimizing the need to write code that
implements the application’s infrastructure allowing the developers to focus on the features of
the actual application. 

Basic modules of applications created this framework use the Fusion web application technology stack, which includes
ADF Business Components, ADF Model, ADF Controller, and JavaServer Faces pages with ADF Faces rich client components.
Business Components focused on creating objects, which
implement the Business Services layer on top of a data source, in a more declarative way.
BC mechanism lets obtain the full list of possible values from the row set of the data source view object.

First part of thesis presents basic information about ADF and the most important issues connected with technology.
Thesis presents simple access to add, remove or edit data from SQL language and after that describes similar solutions in ADF technology.
Next part contains simple designed and implemented Developers Database application. Software consists of information about building 
developers and their investitions, collaterals etc. 
All part of implementation was tested with large number of different criterias. Author tests
functional requirements, graphical interface and performance. Last part of thesis shows differences between
SQL data management and BC. Author indicates pros and cons of both solutions and which resolution use in diffenet situations.
At the end we can find information about further development plans connected with ADF and JDeveloper envirement.

Key words: model layer, SQL language, business components, ADF framework, JAVA, MVC

\addcontentsline{toc}{chapter}{Spis rysunków} 
\listoffigures

\addcontentsline{toc}{chapter}{Spis tabel} 
\listoftables

\addcontentsline{toc}{chapter}{Zawartość płyty} 
\chapter*{Zawartość płyty}
\begin{enumerate}
\item Kody źródłowe programu.
\item Eksport struktury bazy danych wraz z danymi.
\item Skrypty Selenium.
\item Skompilowana (*.ear) oraz zarchiwizowana wersja aplikacji.
\item Kody źródłowe pracy (*.tex) oraz wygenerowany plik pdf.
\end{enumerate}

\addcontentsline{toc}{chapter}{Oświadczenie} 
\chapter*{Oświadczenie}
oświadczenie (brak plagiatu) - usunać po wygenerowaniu spisu treści i zastąpić oświadczeniem od pł

\end{document}
